>From: Göran Krampe <goran at krampe.se>
>Reply-To: goran at krampe.se, The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Squeak and Namespaces
>Date: Mon, 4 Dec 2006 09:45:42 +0100 (CET)
>

>In fact - if you read that post *closely* you will actually come to the
>conclusion that it works very, VERY similarly to my proposal - if you
>exclude the "multi user" aspect of it and change the lookup procedure.

Honestly, I wasn't as interested in the multi-user part.  That would be a 
nice add on, but the rest of it would possibly make nice namespaces.

And yes, the two do have some things in common.  But the difference is:
1) Your solution introduces new syntax
2) Your solution doesn't really add namespaces, just prefixes in a way that 
lends to parsing.

With your set up, every class that is in a namespace has to have some ugly 
colon syntax.  And we have a lot of prefixes now, so it is pretty reasonable 
to expect lots of ugly colons to look at after the change.  And if I want to 
know how many classes are in a namespace?  You have to scan the whole global 
dictionary, no?  A gemstone style solution you could ask the namespace what 
it has in it and it would know.

>It says that you have multiple "spaces" and that the space itself is in
>"itself" as a key. My proposal says that each space is in Smalltalk (the
>global space) as a key - GemStone instead has a list of spaces that it
>looks through one at a time.

At compile time.  And when you compile one method at a time you have more 
time to do things.

>
>GemStone thus has shadowing - the spaces are like layers on top of each
>other - a space early in the array can shadow a space later. Good? IMHO it
>would just get confusing and error prone *in the context of Squeak* . I
>simply don't see the need for shadowing like this - others may disagree -
>read on for an interesting side effect.

Yea, I think we could live without this part in the base.

>I would much rather see:
>
>    myTest := SUnit::TestCase new.
>
>...or as it would be in 90% of the case:
>
>    myTest := TestCase new.
>
>...than the above - when doing an explicit instantiation.

Well in both cases, implicit instantiation looks like:

myTest := TestCase new.

In the explicit case they look like:

myTest := (SUnit at: #TestCase) new.     "Gemstone style (I think thats 
right)"
myTest := SUnit::TestCase new.              "Yours"

For me sticking with the smalltalk looking syntax looks better.  I know 
people are pretty divided on this one (not sure who is the majority).

>
>One IMHO *very* important difference with the GemStone solution is that
>GemStone code can bind differently when recompiled!! In my proposal all
>references are fully qualified in the source so they will always bind to a
>specific key in a specific named space. The only way to get a different
>result is if you have changed the value of the key - or indeed has put
>some other namespace at the same name (highly unlikely).

In the multi-user case you would *want* it too, since different people have 
different rights.  But I'm good with leaving all that out of the base and 
make it downloadable.

And I am with you on not making namespaces so granular.  Sometimes, even 
with python, if the problem is small enough most of the code is import 
statements.  One of the things I like about smalltalk is that it isn't like 
that.

_________________________________________________________________
Visit MSN Holiday Challenge for your chance to win up to $50,000 in Holiday 
cash! 
http://www.msnholidaychallenge.com/default.aspx?ocid=tagline&locale=en-us