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