Hi!

> stephane ducasse wrote:
>>> And, I think imports are critical for scalability - because they a)
>>> declare dependencies explicitly and b) allow the *user* of a
>>> package/global to decide under which name to use them. The Python
>>> module system works that way and it works great.
>>
>> Can you give an example? Do you mean that you can alias them?
>
> No, I mean that a user can decide what's important for him and where to
> qualify and where not. For example, consider that both Tweak and Morphic
> define a class named Button. In Goran's proposal it means that you
> always have to qualify Button everywhere you see it; even in the innards
> of Morphic and Tweak where there is not the slightest chance of it
> meaning anything but what is reasonable in this context. In Python's

If there is another Button *in the image* - yes. But see below.

> module system you could (in the scope you are working in; usually a
> file) decide to either use only Tweak (and not qualify) or use only
> Morphic (and not qualify) or use Tweak qualified and Morphic
> unqualified, or vice versa, or use both qualified.
>
> In either case it puts the user in control about what is important for
> him in the context he is working in instead of the system making
> requirements about qualifications of names because in some distant
> corner of the world a name has been used.
>
> Cheers,
>    - Andreas

There is AFAICT nothing really stopping us from putting some kind of
"imports" into the system later. But it has the following "problems":

1. We loose the "single mode" that is a large part of the Smalltalk feel.
In Squeak I can type an expression anywhere and just "do it". With imports
you suddenly get the inevitable question "In what context?". Anyone having
used VA for Java and its "Scrapbook" recalls that sure, it was almost like
a Workspace - but you had to tell VA in which class it was supposed to
"run" so that VA could figure out the imports. I think this effect is one
of the largest "pains" when using a namespace solution with imports - and
I would guess that the pains people refer to in VW might have something to
do with this.

2. If you have used Eclipse and discovered alt-shift-o (or whatever key
combo it is that "auto fixes" the imports) would agree with the following
observation:

After having discovered this you can essentially work like this:
- Type only "short names" of classes.
- Regularly press alt-shift-o and let Eclipse "fix the imports". It will
ask you if there are more than one match - just like in my solution.

The idea to even have a background thread pressing the key combo for you
every 10 seconds has occurred - since you end up pressing it that often
yourself. :)

What is the consequence? Well, in *practice* this emulates my solution -
only type short names and it asks when there are choices. You hardly ever
look at the imports anymore - which is yet another evidence that you
typically *know* what you use/import.

Ok, I hate the way imports get into my face in Java. And people are more
or less only offering solutions based on very similar models. I really
would like for people to try to think "out of the box" here. And I am not
referring to you Andreas - you already have enough insight. But others
might benefit from at least *contemplating* that namespaces:

- Don't *have* to be hierarchical.
- Don't *have* to use file/class/package level imports.

regards, Göran