[squeak-dev] Environments
Göran Krampe
goran at krampe.se
Fri Jun 29 06:13:31 UTC 2012
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
More information about the Squeak-dev
mailing list
|