[Cuis-dev] Naming conventions

Tue Apr 28 04:20:12 PDT 2020

I still like the idea of using a message as
    PackageName ClassName
but the dot convention made me imagine a simple implementation. Internally
all classes of a package would be prefixed with ‘PackageName.’, and we
would have to change the parser to interpret PackageName.ClassName
correctly as a global name, and change the method bindingOf: to lookup the
association for ‘ClassName’ first as ‘Xxx.ClassName’ for methods compiled
in a class belonging to package Xxx. Looks like it might work without
changing much, I don’t know how hard it would be to change the tools to
display the class names without the prefix when it makes sense.

On Tue, 28 Apr 2020 at 4:32 PM, giorgio ferraris <giorgio.ferraris at gmail.com>
wrote:

> Thanks, Erik,
> I suppose that was the reason, but the end result is just is a bit ugly,
> from my point of view.
> I remember Cincom (or, probably was ParcPlace that started the work) did
> a hard work implementing
> Namespaces in VW, but there the dot is a separator so MyNamestace.MyClass
> looks better than
> MyNamespace@#MyClass.
> Another question is portability..
> But I'm just thinking aloud :)
>
> giorgio
>
> On Tue, Apr 28, 2020 at 11:18 AM Erik Stel <erik.stel at gmail.com> wrote:
>
>> Giorgo,
>>
>> The dot is the statement separator in Smalltalk. What Juan suggest is
>> regular Smalltalk. The @ message is sent to the Smalltalk instance and it
>> will answer the package reference by the argument (a Symbol like
>> #MyPackage). The package has also an implementation for the message @ and
>> will answer a class. So everything is just executed and no special compiler
>> handling.
>>
>> Cheers
>> Erik
>>
>> (Sent from mobile device, please excuse typos and brevity)
>>
>> On 28 Apr 2020, at 10:08, giorgio ferraris <giorgio.ferraris at gmail.com>
>> wrote:
>>
>> 
>> 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/e844c416/attachment-0001.htm>