Re: Namespaces (Was: MNU in tools after loading parcel)

I might be missing something, but AFAICS the proposed change doesn't actually prevent ambiguities. It
just lays down a rule how to resolve them. That however doesn't necessarily mean that the resolution will
always match what you want it to be. You're still open to the problem of someone modifying a namespace
you're importing and suddenly changing the meaning of a name in your namespace, but this time without any
warning. I suspect that what you're proposing was considered in the original design and rejected in favor
of warning about ambiguities and forcing an explicit resolution.

"Reinout Heeck"<vwnclist <at> soops.nl> wrote:
> The current namespace implementation gives us this weird construct of 
> 'Ambiguous reference'.
> It seems this construct introduces a sort of brittleness that we can do 
> without. (If I load a third-party package that is unrelated to my code 
> it may invalidate my code because one of my references suddenly becomes 
> 'ambiguous').
> 
> If the imports mechanism were altered to declare imports as a stack 
> instead of a set, and the lookup rules are altered to stop searching 
> after its first (nearest!) match this class of brittleness goes away. 
> Instead it is replaced with a more manageable one that runs parallel to 
> the brittleness scenarios we know in class inheritance. (Indeed the 
> whole name import mechanism will feel a lot more like the method lookup 
> rules we already know very well).
> 
> So I propose that import declarations be interpreted as an import stack 
> instead of an import set, and note that then technique a) below becomes 
> default/automatic without us needing to know any rules about what 'type 
> of import trumps another type' -- simply because that would be explicit 
> in the ordering in an import declaration.
> 
> There is a silver lining to the 'ambiguous reference' construct: it has