Hi Lex!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> 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?

I agree we shouldn't pepper the user with questions if we can avoid it.
At the same time I still do NOT like the standard "Per class imports
like in Java"-model.

If the code read "Delay" I have no idea which class this is bound to
*unless I look at the imports*.
So the import list for the class will have to be visible somewhere,
right?

And another problem is that the compilation of a method now depends on
the import list. So if you write method A with "Delay" (and choose to
import Tweak::) and then write method B which references "Semaphore"
(which happens to exist in Banana::, but there is also a Banana::Delay
!) then the tools will add Banana:: and suddenly it is not clear anymore
which Delay that method A refers to. In short - in Java the compilation
unit is the class and if you reference something that exists in two
different imports the Compiler will barf. How do we handle all this in
Smalltalk where the compilation unit is the method?

In short - it just feels like a "per class import"-list doesn't fit
well, it seems to me that there are multiple scenarios where it gets
complicated.

IMHO the "don't pepper the user with questions" can be solved more
elegantly with a smarter LookupContext object.

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

I agree with this, we can add smarts. I still don't agree with adding a
per class import list.
Not sure what you meant with "alias" though.

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

I agree that there may be an issue with not having Andreas context
somewhere accessible for people loading his code into their images.

I still want my proposal to stand (fully qualified names in source etc)
but we can always discuss how the LookupContext could be externalized
together with say the Namespace (not the class IMHO).

So it would just mean that the LookupContext could possible be
externalized together with the code somehow. But again - that is easy to
add later on and that would NOT affect my proposal.
 
> -Lex

regards, Göran