To clarify: I was never was for the dot and always favoured the :: notation for namespaced classes. With that one one could create classes like: Seaside::Component Core::Boolean Model::Person GLM::BrickListModel Tx::FontAttribute (see my post on http://forum.world.st/Separator-in-class-names-td4926162.html from 2016). I know this from SmalltalkMT system and it worked nicely. Anyhow: Namespace discussion pop up each year - often in December and mostly because we still not have them ;) The oldest reference you can find is from 2010: http://www.jarober.com/blog/blogView?entry=3462762798 mentioning a Google summer of code project. Then Germán Leiva demonstrates this Namespaces project in Pharo https://www.youtube.com/watch?v=n4I7fSVNX2A then it was declared dead: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2012-June/066765.... Then there was a discussion from 2012: http://forum.world.st/Pharo-and-Namespaces-td4636635.html and one in 2016 http://forum.world.st/Separator-in-class-names-td4926162.html Having proper namespaces would avoid such strange things as in https://github.com/pharo-spec/Spec/issues/813 and solve many other issues (but introduce new ones as well). But as always it is a question of time and resources. It's not only about introducing the namespaces itself - it would also mean to change the tools to support them. With Pharo 8 now more experiments are possible into bootstrapping an own Pharo (possibly with Namespaces): 1. One can bootstrap an own image / have it's own personal "Pharo" using Bootstrap to do experiments https://github.com/pharo-project/pharo/tree/Pharo8.0/bootstrap https://rmod.inria.fr/archives/papers/Poli15a-Onward-Bootstrapping.pdf 2. A class now knows about its environment environment "Return the environment in which the receiver is visible" ^Smalltalk globals and OpalCompiler supports an environment in the CompilationContext. So basically you can compile into a second environment withing the existing running image. 3. There is an experiment on modules called Metalo: https://github.com/guillep/metalo According to what Stef wrote on Discord in #bootstrap channel: "The idea is that we want to be able to edit dynamically module (package + namespace) without for example having to remove a full hierarchy of classes when just we change an import statement in a module. Our goal is to split Smalltalk globals into multiple namespaces one per module." "Metalo includes also supports for editing module, bootstrapping a kernel with modules and new class definitions." Dont know about its state. 4. There is a tool called "Candle" to help you bootstrapping own images: https://github.com/carolahp/pharo/tree/candle so one could bootstrap an own kernel with namespace support or other. Bye T.
Gesendet: Montag, 23. Dezember 2019 um 01:18 Uhr Von: "Esteban Maringolo" <emaringolo@gmail.com> An: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> Betreff: Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)
There are two uses for namespacing: 1. Avoiding class name collisions between different packages 2. Modularization
I don't have the use cases for 2, but Torsten had an idea to support the dot in the class name, that'd solve the problem 1. (e.g. Chronology.Date and YourPackage.Date).
Esteban A. Maringolo
On Sun, Dec 22, 2019 at 8:57 AM ponyatov <dponyatov@gmail.com> wrote:
What is the modern state of namespaces support? Maybe in Pharo 8 (or 9)
I'm going to model some generic async Smalltalk in Pharo, package-bounded namespaces can save me from prefixing every class name.
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html