Hi!

> Sidenote: First I want to say that Lex raises interesting questions. I
> still see a number of issues with using "Java style class level
> imports", but it is interesting to discuss.

Here a few points regarding the "Java import". My feelings about it are:
  - A class can use classes located in another package without having to explicitly write an import statement. A bit like Goran proposal, I can write in my method "void foo() { return my.great.package.MyClass.foo();}". Of course, this is not possible if the class is private.

  - An import statement is not related to a class. A class does not import anything in Java. The import statement is specified for each unity of compilation, which is a file. Several classes can be defined in a file, and in that case the import statement is globally applied.

  - Another issue regarding wildcar. I can do "import my.package.*;" to import all classes of my.package. Now the thing is if I define in my package a new class A, conflicts come if a class A is defined in my.package. It is also valid in the other way around: I can have a class A defined in my package, but my.package evolves and not contains a class A.

Cheers,
Alexandre

> 
> "Andreas Raab" <andreas.raab at gmx.de> wrote:
> > Lex,
> > 
> > > 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.
> > 
> > Yes. That's what I actually meant by "imports" and maybe that's just a bad
> > word. So how about saying that when you load a package, define a new class
> > the names get "advertised" to the lookup context? They are there for you
> > ready to use.
> 
> When people say "imports" I have always assumed they where talking about
> "source level" imports on either class, package or some other level.
> Perhaps I am just stained by Java, but Lex uses the same term. I have
> come to realize that you Andreas did not mean that. :) Terminology is
> hard.
> 
> > > 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.)
> > 
> > This is a small problem in the overall scheme of things. We can always
> > delegate back from the tools to the class - let's see where the current
> > approach leads. As a matter of fact, for the time being I prepare having the
> > context in the tools - it means we're not starting lots of wild definitions
> > about "what the lookup means" in our own classes. Consider it a threshold
> > for the early phases ;-)
> 
> Yes, it seems to me that keeping this issue, for the time being, out of
> the codebase itself we can learn more before starting to make changes to
> the lower levels. If it turns out that Lex is "right" then we can always
> move forward in that direction.
> 
> > Cheers,
> >   - Andreas
> 
> regards, Göran

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