goran.krampe at bluefish.se wrote:
> If you are just talking about a different "way" to store the information
> - I agree, might be easier, need to think a bit more about that. But it
> sounds like you are instead describing an "import" model per class (just
> like in Java), and that is different than what I describe.
> 
> An import model per class (this is not at all what Andreas describes
> AFAIK) makes resolution of names to behave differently "over time".
> First, then the import list is empty and you type "Delay" and there are
> Tweak::Delay and Kernel::Delay to choose you ask the user to choose and
> then you would add "Tweak" as an import to your class.
>
> If you then later type "Semaphore" and there are Tweak::Semaphore and
> Kernel::Semaphore in the system - what happens? Well, if this is a "Java
> style" import you are describing it will not ask this time - just
> resolve to Tweak::Semaphore.

Yes, that was the idea.  Doesn't this sound nice?  Once the system
figures out that you are using Tweak stuff, it keeps giving you Tweak
stuff.  It seems extremely unusual that you would use one Tweak class
but then one Squeak class.  Why pepper the user with questions when you
can tell what they are doing?

If someone really wants to grab a singular class out of a namespace,
without importing the whole namespace, then they can still do it by
explicitly spelling out Tweak::Semaphore.  That seems like a good
tradeoff to me.  Whenever users are doing the normal things, the tools
just do the Right Thing.  Whenever a user wants to do something unusual,
they still can, and in a straightforward way.

There are two things that have slipped by.

First, it seems good to quietly grow the lookup context as the user
works.  They should not have to choose which Delay to use every time
they type it out.  Instead, the tools should automatically choose as
much as possible.  The vast majority of users will not be writing code
that has aliases in it most of the time.  The Delay they wanted last
time is sure to be the Delay they want the next time.

Second, I do not like the idea that only the tools know the lookup
context.  This causes trouble when people share code between each other.
 For example, imagine you install Tweak from SqueakMap and then start
browsing Tweak code.  It will be unreadable if you do not have the right
lookup context, but if the proper lookup context is only stored in
Andreas's image, what are the rest of us to do?  Do we have to tweak our
tools before we can read the code we've loaded?  What if Andreas loads
Tweak into a new image -- does he have to spend time setting up the
lookup context again?

What is so bad about classes having a lookup context?  I don't see the
problem.  I am not suggesting that people type a long list of imports
like in Java, but merely that such a list exist.  The tools can fill in
the lists automatically.  It would be just the same as the lookup
context you guys are discussing would be in the tools, but it would be
stored in the codebase instead of in the tools.  (The tools could still
have a different lookup context if you want, but that is a secondary
issue.)



-Lex