I do not like the idea of using a dot in class names because dot is already used to separate expressions in a sequence. I am pretty sure that using dot may introduce several ambiguities in the parsing process. For example, the following with the current parser will produce the same AST:
someMethod > Chronology.Date > vs someMethod > Chronology. > Date > Using spaces for supporting namespace in theory allows for an implementation that does not require to make several modifications to the compiler (except for efficiency reasons). Using some other separator such as two colons ( :: ) may also solve this parsing ambiguity problem. A single colon ( : ) also posses this ambiguity problem because it could clash with keyword message sends. P.S: A bigger problem that I remember from that ESUG discussion is having namespaced/modularized selectors and extension methods. :) Best regards, Ronie El dom., 22 dic. 2019 a las 21:20, Esteban Maringolo (<emaring...@gmail.com>) escribió: > 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 > > > >
