Hi Lex and all!

(taking a break from messing with SystemDictionary)

"Lex Spoon" <lex at cc.gatech.edu> wrote:
[SNIP]
> I don't think you mean that the lookup context lasts only until the next
> file in, i.e. that literally you only change the default lookup context.
>  That proposal does not accomplish making code readable by default.  If
> I file in Tweak and then Traits, then I end up with the Traits lookup
> context and have to read fully qualified names in the Tweak code.

Not wanting to sound like a parrot :) but again - why would we end up
having to read fully qualified names? You may not be describing my
proposal anymore (not sure) but if you *are* then the only reason for a
fully qualified name to appear in the Tweak code would be if an object
was referenced in a Tweak method that:

Is not defined in the Tweak namespace *and* is defined in at least two
different namespaces in the image.

I would guess there are very, very few such objects (classes).
 
> It is nice that one person is considering this issue.  IMHO, the issue
> is vital and we must work out a way to manage inter-image transfers of
> lookup contexts.  Otherwise, we will create something that is a net
> minus to Squeak.  Without transmission of lookup contexts, people will
> in many cases have to read code that peppered with things like
> "Tweak::Delay".  I'd rather have name collisions than have to read fully
> qualified code like this.

Still can't understand this.

> Does anyone disagree that we need to have inter-image management of
> contexts before we have an acceptible proposal?

Eh, yes! :)

BUT... I don't think we need to call any votes or anything at this
stage.

Personally I wouldn't vote for a namespace solution (ANY solution) to
enter Squeak without first having been hammered on for quite a while. So
we need at least one proposal *with* an implementation to try out and
then sleep on it before even thinking of any decisions.

> I don't know why "import list" has become a bad word, but it seems like
> a direct and simple way to solve the above issue.  Simply let authors
> specify what lookup contexts should be used with the code they write. 

Hmmm, you are using the term "lookup context" here and I am not sure
what you mean anymore.
Is it a Namespace? Or an "Andreas context"?

In my current vocabulary a Namespace is a named Dictionary with symbols
as keys and objects as values. An "Andreas context" or what I
subsequently called LookupContext is an object that is used by Compiler
and Browser to both help resolving unqualified names when compiling
Smalltalk code and to help rendering code in a suitable fashion. My code
currently just has a class called LookupContext with a few class side
methods that I use from here and there. The whole point is that it is
"pluggable" so Andreas could use a different set of rules if he wanted.

> Putting these declarations in classes seems suboptimal but a fine way to
> get going.  Eventually we can let the declarations be put at different
> levels of granularity varying from packages down to individual methods.
>  
> Anyway, I am not attached to the per-class import lists.  However, it is
> essential to have *some* solution to this problem, so let's not reject
> it without replacing it with something else.

Well, we are obviously in violen disagreement :) but I say "Let's not
reject or select *anything* until running code has been presented.".

I will at least be presenting my solution and then anyone will be free
to present his or her solution or criticise what I present.

> Lex

regards, Göran