Squeak and Namespaces

Hi!

> This is pretty good.

My recollection of working with the GemStone setup was that it easily got
"confusing" - BUT... that was *not primarily* because of the setup itself
- but for the reason that GemStone is a multiuser environment.

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.

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.

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.

But if we disregard the above difference in lookup, they are similar:

- Both are non nested. Only one level of spaces.
- Both have the spaces themselves reachable by name.
- Both are compile time bound, but allows explicit runtime binding by
sending messages to the "space" itself.

The example show for the latter was:

   myTest := (SUnit at: #'TestCase') new.

And that code would look exactly the same in my proposal. Then James
stresses that this solution hsa no syntax change - but why exactly is that
a plus?

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.

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 GemStone, if you file in a package after filing in SUnit that
accidentally defines #TestCase (it gets shadowed) and you later *recompile
SUnit* - then it will suddenly bind to the new TestCase. Eh, oops.

As I said, I consider this to be a problem more than a feature. Having
such a dynamic resolution, and NOT having imports - that seems like the
worst kind of combo. ;)

Recall that GemStone is a multi user env and does not have a very active
public community like Squeak has (with many public packages available). I
think they are hardly comparable when it comes to use cases.

> FWIW, I am totally against adding new prefixes.  All classes already
> have an identifier that resolves them to a "package" and that is
> category.  So the long name of Object is really Kernel-
> Objects:Object.

Note that suddenly giving Category a semantic meaning is a rather large
backwards incompatible change. I am not saying bad or good - but it is a
rather pervasive change. And I don't think they serve the same purpose.

I do propose the first part (The PI part) of the category name as the
namespace name in the class creation template though - as they would
probably match say 70% of the time. Mmmm, disregarding the PIs of the base
image - we should probable have them on an ignore-list so that all base
classes always end up by default in the global space.

> Using the one class dictionary per package strategy
> mentioned, I think the compiler should simply prompt the user with a
> menu like:
>
> Ambiguous reference to class "Widget"
> Foo:Widget
> Bar:Widget.

Which btw my proposal does. :)

> It should remember this first time and resolve it that way from now
> on much the way it spots new message selectors and remembers that you
> do indeed mean that name.

That we could easily add to my proposal - a Preference or whatever. It has
been discussed. Currently it has no memory and will ask each time, the
only "feature" it has is that it will not ask if there is a "local" match.
Again, all this is tool policy stuff - we can do it differently for every
tool and every user, and top it off with 20 Preferences. :)

> For the rare instance when one needs to
> reference two classes with the same name in different packages, one
> can type the optional package prefix.

Same in my proposal.

> That would solve the problem nicely from a user's perspective.  How
> to make this work is left as an exercise for the implementer. :-)

IMHO this is how it works in my proposal. I think I have already done the
exercise. :) :)

regards, Göran

Hi!


>>And again, even if there ARE 4 projects using say "Component" - it is
>>not typically so that you happen to have all 4 in your image at the same
>>time.
>
> I'm confused here.  You mean all 4 in different namespaces?  Because if
> so,
> then I can give you an example.  I use Pier.  It pulls in Magritte and
> Seaside.  All three have a Component class.

Sure. We do have a few of these "common words". And they would need to be
shown using :: unless:

- They are used locally (as in "within Seaside" etc), which they are 90%
of the time I guess, so they could be shown short.

- When you *type* them you can still type the short name and it will ask
you which one you mean. And as Todd mentioned we can have the tools
"remember" one of the choices until you explicitly swith to another etc.

regards, Göran

Hi!

I am trying my best. :) I just wondered what you meant.

> I see factors in each direction that are close to a wash.  Visually it
> is uglier, IMHO, though it is a matter of taste.

Again, you would see these colons very, very rarely:

- In the class definition, as the class name.
- In methods referencing a global (=class mostly) where there are multiple
namespaces defining it, AND where the method itself is NOT in one of
those.

IMHO the above boils down to quite few places, especially since we also
IMHO would simply use Smalltalk as the namespace for all of the "basic
image".

So to reformulate the above bullet - you would only see qualified names if
a method in package A references a class in non basic package B which is
also defined in another non basic package using another namespace.

> Regarding ambiguity,
> it has the advantage of decreasing ambiguity, but it pays two
> characters per name to accomplish this, and I am not sure it adds much
> in practice.  In practice, the prefix is almost always all the leading
> capital letters except the last; the only exceptions I can think of
> are classes with protocols in their name (e.g., HTTPSocket).

Again, it only "pays" those colons on very few occasions IMHO. Both
regarding typing and reading.

> Aside
> from that, if you are going to spend two characters, can't you just as
> well add two *meaningful* characters, e.g. SqMp instead of SM?  This
> would appear to disambiguate even further.

Of course, I don't think I was the one that introduced the SM:: example in
this thread (I just kept using it) - I would typically use SqueakMap:: I
think.

> The tool benefits you have proposed are interesting but tricky, and
> are not a clear win.  They are especially tricky when you consider
> code appears in places outside of the normal browsers.  This happens
> all the time in Smalltalk....

If you do not do anything with the tools - then you simply see the
qualified names just like you see prefixed names today - or in other
words, you see some :: here and there and a bit longer prefixes. It
doesn't seem like too much of a pain IMHO.

Ehm, we *already* have this IMHO. We have categories and we have prefixes.
Sure, we could do as Todd says and give Categories a semantic meaning and
skip the prefixes - but it would IMHO cause "too many" namespaces, since
we then would use them for organization and not ONLY to maintain unique
collections of names.

As I have said, I think only one namespace per Project/Group is enough.

> We currently have a single categorization scheme.  It appears
> practical to evolve that existing scheme into a *single* scheme for
> using hierarchical names to disambiguate.  Given this practical
> strategy as an ultimate goal, it seems a pity to move in a different
> direction.

Well, I am not sure. I think having too fine granular namespaces is a
problem. Then we are ending up like Java where they use the "namespaces"
they have mainly for orgaisation causing thousands and thousand of
"islands".

IMHO one of the strengths behind Categories is in fact that they ARE non
semantic (disregarding PI).

> Overall, it is inevitable that some of the feel Frank describes is
> going to get worse when we add hierarchical names of any kind.  Let us
> try to have a clear win before we adopt something that has these
> definite minuses.
>
> -Lex

Well, as I have written a few times now I don't have any high hopes for my
solution getting adopted, even though people keep happily using it in
"emulation mode" all the time (prefixing).

I will probably refine it and try it out a bit myself - mostly because I
am interested in the feel of it - but since the resistance is so strong I
have no energy "fighting" for it more than I have already done - ending
this thread will be the last of it I guess.

regards, Göran

I was thinking of more then just namespaces.  I was thinking I would throw
the question out there, and if enough people said they would donate then we
could make a list of what are the biggest priorities that squeak needs and
none of us are going to do in the foreseeable future.

>
>My design is roughly as follows. I'm still working on it, so it may change:
>

Did you look at the Gemstone stuff that I reposted?  It sounds like that
system is close to your goals and it adds no new syntax (no dot syntax, no
colons, just normal message sends afaik).  And I think the security of it is
nice as well since it looks at the user compiling the code and then makes
the link at compile time.  If you file out your changes and someone else
files them in, it looks like that stuff would get rebuilt so the only
security problem would be if you ship the byte codes directly, but I guess
they probably have some solution for that.

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

>From: Göran Krampe <[hidden email]>
>Reply-To: [hidden email], The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>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

Yes. I used that for inspiration on how to manage import lists. Effectively, you get the same behaviour, but with hierarchical namespaces as an optional extra.

Michael.

Hi!

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

"J J" <[hidden email]> wrote:
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. :)
 
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

[hidden email] wrote:
> 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.

Well, I don't think that is *quite* what I said (unless you have a quote
to back it up ;-) but generally, yes, complex means of searching nested
namespaces can get problematic very quickly. If anything, that was one
of the lessons I took away from the 3.3 modules where effectively
everything always included everything else and wanting to "not-include"
anything became an outright adventure. But I do think there are a few
ways to make that search mechanism explicit and clear (for example, by
avoiding transitive import chains).

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

Given that nobody has used that solution so far, how do you know?

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

I'd be a really interested in seeing an experiment along those lines.

Huh? And why would that be? I fail to see why not having shadowing
necessarily ends up with your proposal - I can imagine various namespace
implementations not having shadowing and not being the same as yours.

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

I don't find that an advantage considering the alternative of a single
humongous namespace that you have to probe for trying to find an unused
name for your project. In particular if it is (like in Python) coupled
with stating the dependencies, e.g., the packages that you are going to
require.

Cheers,
   - Andreas

Hi!

> [hidden email] wrote:
>> 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.
>
> Well, I don't think that is *quite* what I said (unless you have a quote
> to back it up ;-)

Yes, those were not your exact words, didn't mean that. :)

> but generally, yes, complex means of searching nested
> namespaces can get problematic very quickly. If anything, that was one
> of the lessons I took away from the 3.3 modules where effectively
> everything always included everything else and wanting to "not-include"
> anything became an outright adventure. But I do think there are a few
> ways to make that search mechanism explicit and clear (for example, by
> avoiding transitive import chains).

Yeah, I presume there are multiple models that are simple enough to be
viable as a "next step" for Smalltalkers - I just haven't seen much need
for a more elaborate model - given that as we all know prefixes has served
us "kinda ok" up to now and that I have lots of fear for taking away the
"Smalltalk feel".

When people argue for "nested" spaces I would like to hear the actual
semantics intended. In other words - what does the child-parent
relationship mean? Is it that a child sees the same stuff that its parent
sees? Or is it that if you import the parent you also implicitly import
the child? Or the reverse? Or is it merely for organisational purposes?

I don't think that is at all clear. In java it seems to only serve two
purposes - organisational and an decreased probability of picking the same
"namespace name" that someone else has done.

>>> 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.
>
> Given that nobody has used that solution so far, how do you know?

I consider it to be a fair guess given the "rules" for when it is needed
to be shown. But yes, I will try to set up an experiment and we will see.

> I'd be a really interested in seeing an experiment along those lines.

Will see when I get the time.

I meant that the GemStone model described - minus the *list* of namespaces
(thus making them on equal footing) - ends up being more or less my model
AFAICT.

It was not a general claim for all possible models using shadowing. ;)

This is of course debatable. Btw, the variation of allowing nested spaces
in my proposal (as you do in Croquet I guess) is not impossible. I just
think it would be nice to avoid if possible.

For example (thinking aloud) one could envision allowing nested spaces and
then use that to group names that are "private" to the namespace versus
those that are not private. Or "Shy" as I have called it before - meaning
that the "shy names" don't participate as candidates in the pop up menu
when you type a short name. Let's say we have:

Impara::Croquet::Shy::Component
Impara::Croquet::SomeClass
Seaside::Component
Foo::SomeClass

Typing "SomeClass" in a method in Bar::MyClass would ask me which one I
mean - because there are two "non local" such names in the image.

Typing "Component" in a method in Bar::MyClass would resolve without
asking to Seaside::Component and not involve the shy Croquet class.

One argument for using the term "Shy" instead of "Private" is of course
that it is just as accessible as any other name - if you refer to it more
explicitly.

As I said, only "thinking aloud". :) In the above variation allowing
nested spaces the child-parent would not have any semantics other than
being used in the "policy" of when to show names short and when to ask
which name you actually meant.

So the above model would be extremely easy to add to my proposal - I
think. I am not arguing in favor of it though. :)

regards, Göran

For the record, I think namespaces are gay. =P

They're one of the reasons C++ sucks.
I now deeply regret not speaking up against traits which is now causing
the obvious problems as people begin to try to use them.

The best solution to the problem is to implement something along the
lines of my Sphere operating system that I came up with five years ago.
Squeak used to have a large subset of Sphere functionality in the form
of the class Environment. Use that and partition the system into usable
chunks. -- it really is the best solution. =)


--
People say DOS is not reliable, For me it is as constant as the speed of
light.
People say Linux is, I have yet to see it please me for an entire day.

afaik, it is a compile time look up same as yours.  "Compile" being when you
make a method and say "accept" or when you file something in (which explains
why code would run different depending on who loads it).  At least that's
how I understand it.

_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

Hi!

"J J" <[hidden email]> wrote:
Let me rephrase that:

"Comparing those two I am definitely in favor of :: - but note that the
Gemstone style works *in my proposal too* - but then it would be a
normal runtime lookup and not a
compile time lookup - which *given the syntax* is pretty intuitive
IMHO."

Or in other words - in my proposal writing:

        Foo at: #Bar

...is just regular Smalltalk, nothing magical at all. Foo refers to a
Namespace held in a global. And I prefer that because it *looks* like
regular Smalltalk. But if you see :: - then you get a heads up, which is
good - since it is a new concept.

But in GemStone, if I understood it correctly, the Compiler is fed... a
list of System Dicts? Not sure exactly, but in any case "Foo" can be
resolved differently at compile time because of that. I can easily see
all newbies and experts alike fall over that one over and over and
over...

Now - if you are worried about changing syntax - I would actually
consider the GemStone difference much more "dangerous". :)

regards, Göran

Any link for newbies like myself? :)

_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

I believe that it would be Alan's own invention?

http://users.erols.com/alangrimes/UCE/

Alan: could you point me to the bit in that rather large design document that is relevant to Namespaces?

Michael.

Ah I get it.  Yes that is true, their implementation is some what magical.  
Though no more magical then #ifTrue:ifFalse end up being.

>Now - if you are worried about changing syntax - I would actually
>consider the GemStone difference much more "dangerous". :)
>

Honestly, as petty as it sounds, I just care about the colons.  I look at a
class definition and I have to see that.  To me it would feel more smalltalk
to just see an extra "NameSpace:" keyword in the class definition and
"(MyNameSpace at: #Component) new" for explicit class instantiation (i.e.
when you need a class outside of your local namespace).  In fact that feels
a *lot* more smalltalkish to me.

But anyway, that is just my opinion.  If you end up doing it can it at least
be unloadable? :)  Nothing against you personally of course.  I just find it
ugly.  The only thing worse would be dollar signs on the variable names or
something.

_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk