[Cuis-dev] Naming conventions

giorgio ferraris giorgio.ferraris at gmail.com
Tue Apr 28 01:08:13 PDT 2020


Hi, Juan,

probably there is something that makes it faster using what you propose,
but a general convention between languages is a dot as a separator for
namespaces. VW is adopting this. (and BTW it seems more elegant too...) .
Any case, I just started tasting Cuis water, and I have to say that, after
the first moment of confusion (starting with git seems not natural for an
old smalltalk programmer...) , I begin to appreciate the work you did in
these years.
ciao
giorgio



On Mon, Apr 27, 2020 at 11:19 PM Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Folks,
>
> On 4/27/2020 12:52 PM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> I also dislike prefixes a lot. But fortunately name clashes are less
> common in Cuis because there are not as many classes as in Pharo.
> Personally, I’d love to have namespaces, or have class names be local to a
> package.
>
>
> Ok, this got me thinking. So, what would it take to do just that?
>
> We could make each package be a namespace. That means that classes that
> are defined in a package will not be globals. But, any package declaring a
> prerequisite would also behave as if in Python you did 'From package import
> *'. So, the compiler would know that it is compiling some code for some
> package, and it would try to find class names in all packages that were
> declared as prerequisites.
>
> This would have the added benefit that the compiler would check for you
> that you actually declared prerequisites. Code not in a package would not
> have access to classes defined at any package.
>
> Usually, there would be no need to specify namespaces when accessing
> 'globals', even if they belong in a different package/namespace. Just
> declaring the prerequisites for your package just once, will do. The only
> case where explicit call for a namespace would be needed, is if you ask two
> prerequisites, they both define classes with the same name, and there is
> ambiguity. In such casses something like:
> a := `Smalltalk@#PackageName1@#ClassName` new.
> b := `Smalltalk@#PackageName2@#ClassName` new.
> would work as expected. See that class resolution is done at compile time
> because of the use of backticks. So there's no performance penalty. Also,
> there's no new syntax!
>
> If we add package names to the Smalltlak global namespace, then we could
> also do:
> a := `PackageName1@#ClassName` new.
> b := `PackageName2@#ClassName` new.
>
> Again, this is only when the case is that you decided to depend on two
> different packages that happen to clash. So, you are already aware of the
> situation. This would never get in your way when good old Smalltalk would
> do!
>
> There's some work to be done in Browsers and other tools, but I feel it is
> not too much...
>
> Also note that I'd not include nested namespaces, just like we don't have
> nested packages. I'd also avoid having namespaces as a separate thing from
> packages. I'd have a single concept for both. So, it would be simpler than
> what is available in other Smalltalks that support namespaces.
>
> Does this make sense? I am missing something?
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
>
> On Mon, 27 Apr 2020 at 10:46 PM, giorgio ferraris via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> Hello,
>> prefixes have a long story, in use also on  VisualSmalltalk or SmalltalkV
>> long, long time ago. Not having namespaces on many Smalltalk dialects makes
>> prefix the only (ugly) solution.
>> The resulting names are horrible, I personally dislike it a lot, but
>> class' names clashing is something that could easily happens.
>>
>> ciao
>>
>> giorgio
>>
>>
>>
>> On Mon, Apr 27, 2020 at 5:34 PM Erik Stel via Cuis-dev <
>> cuis-dev at lists.cuis.st> wrote:
>>
>>> Hi Ken,
>>>
>>> I think you just answered my question ;-).
>>>
>>> It can indeed be a Pharo ’thing’. In Pharo (default image) you have
>>> class names like ’ZnWebSocket’. It represents a WebSocket and comes from
>>> the ‘Zinc’ framework. I think it coexisted with WebSocket for some time
>>> (the later is no longer part of the default Pharo image). Also ‘MCPackage’
>>> is a package from Monticello (the versioning system). A full name like
>>> ‘MonticelloPackage’ would have solved that issue of name conflict I suppose.
>>>
>>> Regards,
>>> Erik
>>>
>>>
>>> > On 27 Apr 2020, at 17:13, ken.dickey at whidbey.com wrote:
>>> >
>>> > On 2020-04-27 07:28, Erik Stel via Cuis-dev wrote:
>>> >> Hi,
>>> >> Short question:
>>> >> Also using Pharo, I’m used to creating classes with prefixed names
>>> >> because of possible name collisions. What is the Cuis take on these
>>> >> prefixes? I do not see any prefixes being used in the
>>> >> packages/features I’m using at the moment.
>>> >> Regards,
>>> >> Erik
>>> >
>>> > Examples?
>>> >
>>> > What is the context?
>>> >
>>> > Not being a Pharo user, I have no idea what you are talking about.
>>> >
>>> > Typically, one wants to use meaningful names in a way that orients one
>>> and makes code reads like sentences.
>>> >
>>> > Note that the base Cuis image typically has between 500 and 600
>>> classes.  The latest Pharo base image has over 9000 classes.  Perhaps the
>>> (pre)fix is for a Pharo problem..
>>> >
>>> > -KenD
>>> >
>>>
>>> --
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200428/5badb64f/attachment-0001.htm>


More information about the Cuis-dev mailing list