Hi Stef!

Sidenote: A bit curious about "Stef" vs "Stephane" though. :)

=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
> > I think this should be determined by the current LookupContext, say, 
> > LookupContext>>defaultNamespaceForSubclassOf:inCategory:.  That way 
> > you could implement a default policy that did whatever you liked (same 
> > namespace as superclass, same namespace as existing classes in the 
> > same category), but leave the door open to things like a 
> > NamespaceBrowser that provided a more specific context.
> 
> I have problem to understand what is a LookupContext and why we would 
> like to have multiple of it. May be my understanding of namespace is 
> too simple. Does it means that I can change the lookup of all the 
> symbols in a namespace by plugging another lookup context?

No not really! :)

The LookupContext (providing 3 class side methods in category
"protocol") does only two things:

1. Help the user in turning unqualified names (when entering code) into
qualified names. This is done at compile time. This is crucial to
understand what is going on: ALL references are thus turned into
qualified names in the actual method source!

2. Help "rendering" code in tools so that we don't have to read all
those qualified names. :)

So by replacing LookupContext (those three methods currently) with
anoter implementation you can only affect the above two things.

> Does it 
> really make sense to have that? May be andreas needs that to block 
> certain names.

It makes sense since the tools we use to author code can use different
ways to find the qualified names. I mean, heck - it could even employ a
little "alias list" or whatever - remember, it all turns to qualified
names in the source! So Andreas is free to do what he pleases. And
others too. It is very much similar to "alternate syntax" etc.

> I have the impression that you use a kind of strategy 
> pattern for the lookup while I'm wondering why just letting the user 
> willing to have a special namespace behavior subclass from namespace 
> and create what it need. Why do we need that? I'm really puzzled.

Because I don't want multiple *Namespace* implementations floating
around - that would be like having multiple flavours of the Squeak
Compiler or any other fundamental piece of the machinery. Multiple
*tools* to author code on the other hand is fine by me!

> Stef

regards, Göran