Squeak and Namespaces
goran at krampe.se
goran at krampe.se
Mon Dec 4 22:04:36 UTC 2006
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
More information about the Squeak-dev
mailing list
|