Hi!

> > To sum up, what I suggest is:
> > -a namespace should state what it needs, but not from where to get it 
> > (no hardwired import).
> 
> That would be equal to my proposal. With the difference that the source
> has qualified names - but we could (future extension) allow "aliasing"
> between prefixes - like saying that - ok, from now on Tweak:: maps
> instead to HackedTweak:: in this image. I don't like aliasing "per
> class" because I don't think a class should ever be used with another
> name than the author gave it - it would cause tremendous confusion.

Noury said that the provider namespace/package/module does not have to be specified within the client.
And I think that you are saying the opposite: classes contained in a namespace knows where the necessary classes come from.

I feel that what Noury and you are saying are opposite.

> > -allow refering to classes with different names (aliasing). This means 
> > not rely on names for retreiving classes required by some namespace. In 
> > order to keep the "optimistic" approach of Goran, this should be viewed 
> > as an extra possibility. When loading a new namespace, the system can 
> > try to fulfill requirements based on class names, but one should be able 
> > to refer to classes with different names.
> 
> I am sorry, but I really don't agree on this last one - aliasing is IMHO
> a BAD idea. It just widens the gap between "what I read" and "what it
> is".

You might need to reuse in one single scope two named entities. And it might happen that these have a same name...

Cheers,
Alexandre

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