A little namespace "proposal"
bergel at iam.unibe.ch
Thu Apr 15 14:29:57 UTC 2004
> > 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
You might need to reuse in one single scope two named entities. And it might happen that these have a same name...
Alexandre Bergel http://www.iam.unibe.ch/~bergel
More information about the Squeak-dev