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

In Java the compilation unit is a file, and not a class.

I believe to put the import at the level is a class is wrong. A class is not a module/package. 
This is why I also believe that VisualWorks has taken a wrong decision in the way they have introduced Namespace.

Cheers,
Alexandre


> 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

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.