Squeak and Namespaces

Göran Krampe goran at krampe.se
Thu Nov 30 09:35:10 UTC 2006


Hi!

> On Nov 30, 2006, at 12:45 AM, Göran Krampe wrote:
>> It means that I can load 34 other packages into my image and as
>> long as we
>> don't have *namespace name* clashes (like two people using the same
>> name
>> for their namespace) nothing funky will happen in my source. All
>> references are still perfectly correct.
>>
>> The only diff is that when I *browse* the code that earlier said
>> "Dictionary" now may say "Kernel::Dictionary" because my image now
>> also
>> contains "Joes::Dictionar" and "Schmoes::Dictionary".
>
> There's one thing I'm not clear on from the writeups is how legacy
> and namespaced code
> are meant to interact in this proposal, in the phase were it is being
> introduced.
> Apologies if this has been covered, its been a long thread.

You have no idea how long. :)

> Sample scenario
>
> 	I take a clean 3.9-ish image.
> 	I load the namespace support.
> 	I load a package that introduces the classes Someones::SharedQueue
> and Someones::Something
> 		<would that work, given that there is a naked SharedQueue in the
> system?>

Yes. You now have two classes, one named #Someones::SharedQueue and one
named #SharedQueue. Just like with prefixes today.

> 	I go into a method in Someones::Something and type
> 		SharedQueue new.
>
> 		Does this prompt a disambiguation question,
> 		and if so, how do I indicate that I want to use the system's
> SharedQueue?

This is a good example. If you had written SharedQueue in Foo:: then when
saving a popup menu comes up and asks which one you want. You select which
one and Squeak will correct the code by inserting the prefix, if you
selected Someones::SharedQueue.

But if you type it in Someones::Something then there is a policy that says
that "local" references (=typing a short name that has a match in the
namespace of the class that you are editing, regardless of other matches
in other namespaces) are assumed to mean the local one - so it will not
ask and it will not expand visually to Someones::SharedQueue - BUT the
source will read "Someones::SharedQueue". Theoretically we could meet half
way - not asking, but still expanding it visually - but that is not how it
works today.

I can't verify this right now - but I am pretty sure this is how it works
and how I meant it to work - local references is such an obvious special
case that I think it is worth "deviating" from the rule that a short name
always means that there are no other such short names in any of the other
Namespaces in the image.

But note that this "lookup policy" for local references is actually a
"Tools Issue" - we could even make that a Preference! Or you could hack in
"imports" and use that. And I have isolated this policy in the code in a
single class to make it easy to experiment with.

> The answer earlier about how yes, one could use existing categories
> as defaults,
> but you'd do it in the class-creation template, prompted this question.
> What is the default full name of an existing class,
> when your changes are first incorporated into an image?

It depends on how we wish to partition the classes we already have, see
below.

> I.e. where did 'Kernel' come from in your example above,
> if not by automatically namespacing legacy code by category?
> And if that is done, does it immediately affect the content of all
> fileouts
> and package commits?

We have three choices:

1. Keep the basic classes unprefixed just as now.
2. Introduce a single space for all basic classes, like Kernel::.
3. Cut the basic classes up in several namespaces.

IMHO #3 is bad. We aren't talking about Modules nor Categories. The base
classes are maintained by the same group of humans (=us) and we can make
sure all their names are unique - so we should just have ONE space.

#2 was what I first envisioned - but now that you posted I recollect that
someone thought it was better to just keep them in the "unprefixed
Namespace" which equals Smalltalk.

So disregard my previous post and forget about Kernel:: - I recommend #1.

> Or is it the case that you can't introduce a namespace-prefixed name
> whose base name is also present as a naked legacy class name?

If we go for #1 - that is correct since all Namespace instances are also
globals. In other words - at the same instant you create Foo::Bar, the
system will instantiate the class Namespace and put that in Smalltalk at:
#Foo.

Sorry for the confusion.

regards, Göran




More information about the Squeak-dev mailing list