Hi!
(just posting to make sure we understand the nuances here)
"J J" azreal1977@hotmail.com wrote:
From: Göran Krampe goran@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:
- Your solution introduces new syntax
- 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