[Cuis-dev] recommendations for class name prefixes

[Andres Valloud]

Why is it that I can make a C program with a function called memcpy(), 
avoiding conflicts with whatever the standard library or even the 
compiler itself provides?

On 6/22/24 10:06 PM, Luciano Notarfrancesco via Cuis-dev wrote:
> On Sun, Jun 23, 2024 at 11:44 Andres Valloud via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
> 
>     What is a "program"?
> 
> 
> Not sure what you’re thinking… and I guess I should say “exactly!”. The 
> association between a name and a concept depends on context, you can’t 
> expect me to know what kind of “program” you’re talking about without 
> context.
> 
> 
> 
> 
> 
>     On 6/22/24 8:50 PM, Luciano Notarfrancesco via Cuis-dev wrote:
>      > I think it is normal to have name clashes in big systems with a
>     global
>      > namespace, it happens in natural languages as well (and in some
>      > languages a lot more than in english or spanish). I appreciate the
>      > simplicity of not having namespaces, but I think using longer
>     names with
>      > extra words is not a good solution. Even in a base image as small
>     as we
>      > have in Cuis there are some important names already taken like
>     Object,
>      > Set and Point. Not being able to use Set is particularly
>     annoying, since
>      > there’s no other name for sets… but well, it’s ok, it could be
>     worse (in
>      > a system with 10k classes, for example)
>      >
>      > On Sun, Jun 23, 2024 at 05:58 Juan Vuletich <juan at cuis.st
>     <mailto:juan at cuis.st>
>      > <mailto:juan at cuis.st <mailto:juan at cuis.st>>> wrote:
>      >
>      >     __
>      >     On 6/20/2024 2:19 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>      >>     It’s up to you. I don’t do it, and i think most people in Cuis
>      >>     dont do it either (perhaps becase Cuis is smaller than other
>      >>     Smalltalks, so it’s less prone to name clashes).
>      >>
>      >>     On Thu, Jun 20, 2024 at 06:39 Mark Volkmann via Cuis-dev
>      >>     <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>
>     <mailto:cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>> wrote:
>      >>
>      >>         From what I understand it is standard practice to add a
>     prefix
>      >>         your classes to avoid name conflicts with classes from other
>      >>         packages. Is it recommended to do this for every class you
>      >>         define? Are there guidelines on choosing prefixes such as
>      >>         their length (2?) and case (all uppercase?) ? Is there a
>     list
>      >>         of well known prefixes used by popular packages that we
>     should
>      >>         avoid using in our own class names?
>      >>
>      >>         ---
>      >>         R. Mark Volkmann
>      >>         Object Computing, Inc.
>      >>         --
>      >>         Cuis-dev mailing list
>      >> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     <mailto:Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>>
>      >> https://lists.cuis.st/mailman/listinfo/cuis-dev
>     <https://lists.cuis.st/mailman/listinfo/cuis-dev>
>      >>         <https://lists.cuis.st/mailman/listinfo/cuis-dev
>     <https://lists.cuis.st/mailman/listinfo/cuis-dev>>
>      >>
>      >
>      >     The question is: why do names clash? I can think of two reasons:
>      >     - Duplicated concepts. A redesign is in order. Each concept
>     should
>      >     appear once.
>      >     - Names are too generic. Things that are not the same are
>     named the
>      >     same. Renaming is in order to clarify.
>      >
>      >     The only times I had names clashing, and I still wanted them to
>      >     coexist was during merge of different codebases. For that, a
>     rename
>      >     with some prefix is appropriate. Any prefix would do. It
>     should be
>      >     as short lived as possible.
>      >
>      >     HTH,
>      >
>      >     --
>      >     Juan Vuletich
>      > cuis.st <http://cuis.st>  <http://cuis.st <http://cuis.st>>
>      > github.com/jvuletich <http://github.com/jvuletich> 
>     <http://github.com/jvuletich <http://github.com/jvuletich>>
>      > researchgate.net/profile/Juan-Vuletich
>     <http://researchgate.net/profile/Juan-Vuletich> 
>     <http://researchgate.net/profile/Juan-Vuletich
>     <http://researchgate.net/profile/Juan-Vuletich>>
>      > independent.academia.edu/JuanVuletich
>     <http://independent.academia.edu/JuanVuletich> 
>     <http://independent.academia.edu/JuanVuletich
>     <http://independent.academia.edu/JuanVuletich>>
>      > patents.justia.com/inventor/juan-manuel-vuletich
>     <http://patents.justia.com/inventor/juan-manuel-vuletich> 
>     <http://patents.justia.com/inventor/juan-manuel-vuletich
>     <http://patents.justia.com/inventor/juan-manuel-vuletich>>
>      > linkedin.com/in/juan-vuletich-75611b3
>     <http://linkedin.com/in/juan-vuletich-75611b3> 
>     <http://linkedin.com/in/juan-vuletich-75611b3
>     <http://linkedin.com/in/juan-vuletich-75611b3>>
>      > twitter.com/JuanVuletich <http://twitter.com/JuanVuletich> 
>     <http://twitter.com/JuanVuletich <http://twitter.com/JuanVuletich>>
>      >
>      >
>     -- 
>     Cuis-dev mailing list
>     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>     <https://lists.cuis.st/mailman/listinfo/cuis-dev>
> 
>