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.html 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" <emaring...@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 <dponya...@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 > > > >
