[GOODIE] Namespaces-gk

stéphane ducasse ducasse at iam.unibe.ch
Fri Apr 16 10:17:45 UTC 2004


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

my laziness

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

Ok I understand better I was thinking that this was about lookuping as 
the names
mentioned it. But this is about rendering.

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

ok I prefer that. I was really afraid by my dark thoughts.

Stef
>
>> Stef
>
> regards, Göran
>




More information about the Squeak-dev mailing list