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