[Cuis-dev] Fwd: Re: Namespaces?

[Andres Valloud]

Here's a problem that will be related to that of "namespaces", whatever 
that means.  Why are we still depending on having a running system to 
load code?  That is, what happens when we load old code into a system 
that changed the compiler (because e.g. "namespaces", whatever that 
means)?  A simpler task to solve here would be to provide syntax 
elements for all the objects that can be represented in source code.

On 5/13/19 21:13, Luciano Notarfrancesco via Cuis-dev wrote:
> On Mon, May 13, 2019 at 8:02 PM ken.dickey--- via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
> 
>     One thought is to have a "package namespace variable" which can be
>     set in the code browser.
> 
>     The default would be #Smalltalk (and associated intern dictionary),
>     but setting a package namespace could cause all code to be
>     recompiled to use the package's internal intern dictionary.  The
>     code browser would make new method names be interned in the current
>     package namespace (-> use package intern dictionary).
> 
> 
> The idea seems very powerful and it is tempting to take it all the way 
> and use it for for method selectors too. But it seems to me it could get 
> very complex. In a first try I would use it only for class names, to 
> isolate classes defined within a package. just to solve the problem of 
> having 2 packages defining classes with the same name, or a package that 
> defines a class with a name that already exists in the base image. For 
> example, changing the method 
> subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: 
> to automatically deduce the package where the class name should be 
> internalized from the category name, or perhaps extend the keyword to 
> include a namespace: after category:. But this already gets a little 
> complicated, you have to consider what happens when you move a class to 
> another category...
> 
>