From: Göran Krampe goran@krampe.se Reply-To: goran@krampe.se, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@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-u...