Hi!

Noury Bouraqadi <bouraqadi at ensm-douai.fr> wrote:
> Hi,
> 
> Goran, I like most of what you proposed.
> After reading Andreas answer, I started thinking about imports.
> I belive that to increase reuse opportunities imports should not be 
> bound inside namespaces.

Right now we have some confusion of terms. If a namespace is the "named
list of names" and not the "Andreas-context", then I agree. :)

> Instead, when loading a namespace into an image, one should be asked to 
> link names
> that are not resolved inside the loaded namespace with objects available 
> in other namespaces
> already in the image.

That is how I would want it to work I believe, reading on...

> Example
> Suppose I have namespace A providingclasses L and M.
> Then I load/create namespace B where X and Y are not bound.
> System should ask me wich classes to use for X and Y. I can choose
> to L and M. Then X and Y in namespace B are just aliases to L and M.
> 
> Now, I "fileout" my namespace B so it can be used in another image 
> (Andreas, should I talk about
> another "context"?) with two namespaces C and D. Suppose that C holds a 
> class Z and D holds
> a class W. Here, I can bound X and Y of namespace B to Z and W (that are 
> in two different
> namespaces).

Hmmm. Ok, I think I understand your model, response below.

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

> The location (namespace) of imported classes 
> should not be visible in the code inside namespaces (so no need of extra 
> syntax stuff and source code never change).

Note: In my solution source code doesn't change either. It just
"renders" differently in the viewers. It's like the alternate syntax
switch or whatever.

> But, one should be able to 
> findout connections between namespaces.

That seems very reasonable. And trivial in my proposal I think.

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

But your post made my thoughts even more clear. :)

> Noury

regards, Göran