[Cuis-dev] Naming conventions

[John Pfersich]

Sounds great to me. 

/—————————————————————/
For encrypted mail use jgpfersich at protonmail.com - Free account at ProtonMail.com
Web: https://objectnets.net and https://objectnets.org
https://datascilv.com https://datascilv.org


> On Apr 27, 2020, at 14:20, Juan Vuletich via Cuis-dev <cuis-dev at lists.cuis.st> 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 Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://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
> 
> -- 
> 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/20200427/0b5f3045/attachment.htm>