Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

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

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 <[hidden email]> wrote:

Was there ever any reasonable solution/proposal to that issue ?

Best,

Kasper

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.