Bert Freudenberg <bert at impara.de> wrote:
> What if we store the lookup context with the file-out? That way, 
> another user would see exactly what the author intended.
> 
> Whenever we file out something, be it a single method or a package 
> containing hundreds of classes, we could just store the LookupContext 
> as a prefix. This would define the "default view" when I later file in 
> this piece of code.

If I understand correctly, this approach seems to lead back to having
lookup contexts be attached to various parts of the code base, and also
having lookup context modifications be something that change sorters can
deal with.  Notice that if I file in different code from four different
authors, the system must store four different lookup contexts and keep
track of which context goes with which author.

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.

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.

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

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


Lex