Hi all!

On 06/29/2012 06:48 AM, Chris Cunningham wrote:
> Maybe the auto-aliaser would need to detect that the new code
> references a dual-defined class, and asks which one it should use?  in
> other words, 'partially' auto alias.
>
> -Another Chris

Interesting, some of these last ideas would make the end user experience 
similar to my Namespace implementation (for the insatiably interested: 
http://swiki.krampe.se/gohu/32)

In that solution it works like this:

- Classes can optionally be named "Fruit::Orange" instead of just "Orange"

- When you look at source code with "Fruit::Orange" in it, it will 
"render in the browser" as just "Orange" iff there is just one Orange in 
the image. If there is also a "Colors::Orange" then it will 
automatically suddenly render in full.

- If you try to compile "Orange" (in a Workspace or in a method) the 
tools will throw up a popup menu asking if you meant "Fruit::Orange" or 
"Color::Orange". And it will autoexpand it to its full name when you select.

- "Prefix" also automatically refers to an instance of Namespace which 
is a global and acts like a Dictionary. Thus Namespaces are reified.

Well, that's about it. Essentially it is prefixes like we have today - 
but with a clear separator (::), and reification of Namespaces.

Being able to "pick another Namespace" when importing code (typically 
holding a map of these aliases so that code can still find its way) was 
never implemented but planned.

So you end up with two Fruit packages - the idea was that you can import 
one of them into another Namespace like OldFruit and the image would 
contain this knowledge so that other packages can still resolve 
references to OldFruit classes, and ask etc.

Anyway, intrigued to see where you end up! :)

regards, Göran