goran.krampe at bluefish.se wrote:
> 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?

Yes, and this seems good to me.

If you see Delay in some code then you are very likely to know which one
is being spoken about in the code.  You usually know whether you are
reading Squeak code or Tweak code.  And in the less frequent case that
you are not sure, you can either look at the import list, or you can
click on the variable and do "explain".

This is an issue we already have and that will not go away under any
reasonable proposal I've seen, including the "quick proposal" baseline. 
If you see Delay in the quick proposal baseline, you still do not know
if it is a class variable or an instance variable or even a temporary
variable.  To know for sure you must either examine the class definition
carefully, or you must use the "explain" menu item.

I find this situation just fine.  It's lexical scoping at work.  When I
browse a class, I accept that I need to know the lookup context of the
code.  When I browse my own code I will know what the context is, and
when I browse someone else's code, I can easily check what the context
is.

I don't like the idea of fully qualifying stuff all over the place just
in case some user gets confused.  It's a pessimistic stance that harms
more often than it helps.  I would much rather leave the default
presentation up to the author.  Lexical binding means that the tools can
always expand and show more information whenever the user desires;
showing less information--i.e., more focussed information--requires an
author's touch.


Let me give an analogy from another place in computerdom where I have
practical experience: indentation in text editors.  Many text editors
can automatically indent C code, but doing it properly requires the
editor to know what style of indentation is being used in the particular
file.  The way it's done in Unixdom most of the time, however, the C
files do not themselves contain an indication of the style used. 
(Sometimes, but not usually).  Thus, I must manually configure my editor
before I can edit the code in these files.  It's a major pain.

The tools-only approach to namespace imports is actually worse than
this.  While I must set up my C indentation to *edit* other people's
code, we are talking about setting up a LookupContext before I can even
*browse* other people's code.  That seems like a major pain and a big
step backwards over the simplicity of browsing Smalltalk right now.

Overall, tools-only lookup contexts look like a fine way to start, but
let's go ahead and start thinking ahead to where we want to get, lest we
code ourselves into a corner.  The namespace listings need to be in the
code *somewhere* or we are going to add a lot of nuisance to people
browsing code.  Classes seem like a reasonable place to put them, but
make packages would be an even better place.  And most likely, we will
want to have the option of putting  import lists in different places,
everywhere from method to class to package.



> And another problem is that the compilation of a method now depends on
> the import list. 

This is true whether the import list is in the tools or in the code.



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

I don't see an extra complexity anywhere.  Your main argument seems to
be that it can confuse users to use someone else's lookup context.


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

Yes, that was a separate issue.  I'm glad everyone is sensitive to this
issue.




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

I meant aliases for namespaces themselves, not for elements of
namespaces.  But it points to bigger issue.

The specific issue is that if there are two implementations of URL's,
I'd like to be able to have a NewURL namespace and an OldURL namespace,
plus a URL namespaces that is an alias for one of these two.  Then I can
swap implementations by swapping the alias.

That's not the most important thing.  More generally, I'd like namespace
issues to remain maintainable by users, even if tools fill them in
automatically to begin with.  I'd like to be able to write a class that
imports NewURL, and then switch it to OldURL.  Or, I'd like to be able
to prefix a class with an import of NewURL, which overrides the URL
classes that are in Squeak.


Also, it seems useful to have some large generic aliases like
NetworkingStuff and Morphic and Squeak and Tweak that people can import,
so that they do not have to import loads of individual namespaces to get
anything done.  Thus, it seems good to add in some inheritance between
namespaces at some point.



-Lex