Hi Aaron,

as can already seen from this thread, (Squeak times: Namespaces) seems to  
be not easy because multiple requirements may clash.

We should define how namespaces work, my suggestion:

- concept: a class defines a namespace, is authoritative
- atoms: classes and [parts of] their state are atomic namespaces
  >= "namestate"
- composition: a namespace is a container with 1:n components, a namestate  
is a component with 1:1 container
- uniqueness: a namestate and its full name are unique, its atomic name  
*must* not

There *should* be some syntactical emphasis so that the developer (and  
Shout) can understand!

Motivation for syntax: we say SmallInteger and LargeInteger to subclasses  
of Integer and obviously prefer the opposite direction for a namespace  
hierarchy. Let's replace the suggested :: by a legitimate binary message

  Morphic >~ View
  Tweak >~ View
  System >~ Default >~ Compiler
  My >~ Terrific >~ Compiler

The compiler *should* be extendable by a namespace/namestate  
implementation. Of course the implementation of #>~ depends on the  
run-time used (VW, Squeak, etc) and the default implementation is DNU (for  
Xtreme speed of development ;-)

And Class#>~ can be overridden in support of specialized namestate  
resolution during fileIn and accept (I mean alt-s in the browser).

My CHF 0.05 :)

/Klaus

P.S. in the above, nothing much is new.

P.P.S. if I had a whish free then I'd like to drag'n'drop namestate in the  
browser (Andreas' step towards enabling scalability of development).

On Tue, 21 Nov 2006 17:32:10 +0100, Aaron Reichow <revaaron at bitquabit.com>  
wrote:

> Ahoy!
>
> I know this might sound like a naive question... But why haven't we  
> implemented namespaces yet?  I'm sure there have been some attempts- but  
> what is the status of namespaces in Squeak?
>
> I ask because it seems that, to me, it would be relatively easy to  
> implement an intelligent namespace system in Squeak, something we all  
> could decide on.  It could even offer backwards compatibility in that,  
> for now, all the classes in the image are just part of the default  
> namespace, that way nothing gets broken.
>
> Ideas? Thoughts? Maybe a pointer to a discussion where this was already  
> hashed out? Thanks!
>
> Regards,
> Aaron
>
>