Hi!

(just posting to make sure we understand the nuances here)

"J J" <azreal1977 at hotmail.com> wrote:
> >From: Göran Krampe <goran at krampe.se>
> >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.

Eh, IMHO they are just as much "namespaces" as any other kind.
And moving to a multiple-dicts internal implementation - which I btw
considered - is much, much harder.
In fact, Andreas told me to just don't go there - it is a world of hurt.

> With your set up, every class that is in a namespace has to have some ugly 
> colon syntax.

But as I have said many times now - only visible very seldomly.

> 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 

I disagree, I would say it is pretty reasonable to not expect lots of
them.
But this I intend to demonstrate in fact, so we will see.

> know how many classes are in a namespace?  You have to scan the whole global 
> dictionary, no? 

Yes, but it still is pretty quick you know - about 6 ms on my box (just
a quick test asking a Namespace for its keys).
And as you yourself note - all these things are typically compile time.

> A gemstone style solution you could ask the namespace what 
> it has in it and it would know.

Sure, you can do the same thing with Namespace in my proposal - it
mimics a Dictionary.
Here are some "print its" - I have a class Fooo::Bar in the system (thus
I also have an instance of Namespace sitting in Smalltalk at: #Fooo) and
then I can alt-p some expressions:

	Fooo keys --> a Set(#Bar) "acts just like a Dictionary"

	Fooo at: #Bar -->  Fooo::Bar "dynamic lookup, just like in GemStone"

	Namespace newNamed: #Boo. "create a new Namespace manually, this is
done for you if you create a Boo::Blabla class"

	Boo addClass: Fooo::Bar "add the existing Fooo::Bar class to the Boo
Namespace, it will obviously be remove from Fooo:: then"

	Fooo keys --> a Set() "yup, gone"

	Boo keys --> a Set(#Bar) "and there it is"

	Boo::Bar name --> #Boo::Bar  "this last one is hard to show in an
email, but I wrote "Bar name" and pressed alt-p, it then autoexpanded
Bar to Boo::Bar (in place in the workspace) and printed #Boo::Bar. In a
browser this would not be visible, since it suppresses the Boo:: - but
currently the Workspaces do not do that, which is nice when debugging
this."

 
> >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.

Yes, I was only making clear the difference. Performance is
uninteresting IMHO.

> >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.

Eh, but that is an INTEGRAL part of the GemStone setup. That is the
whole idea with having a LIST in the first place.
If you don't want shadowing then you land on my proposal. :)
 
> >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.

Well, my proposal does not have "implicit" instantiation in the sense I
was after - as in "what this will resolve to depends on what you have
filed in since the last time".

> 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).

Comparing those two I am definitely in favor of :: - but note that the
Gemstone style works too - but then it is a runtime lookup and not a
compile time lookup - which is pretty intuitive IMHO.
 
> >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.

I have worked quite a bit with GemStone and *I* would definitely never
want that and I don't think I am alone.

>  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.

regards, Göran