A little namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Fri Apr 9 10:34:25 UTC 2004


Hi all!

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.

"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



More information about the Squeak-dev mailing list