On Fri, Jun 29, 2012 at 3:32 AM, Bert Freudenberg bert@freudenbergs.de wrote:
Or, do nothing at all. The new binding would simply be shadowed.
Ah, good point. That's a fourth option.
Maybe aliasing isn't the best solution to resolve ambiguities?
What if there was no aliasing, but names would strictly be resolved in order of import? That is exactly as your implementation currently works, right?
Yes, although so far I've only imported Smalltalk, not other environments.
To refer to a shadowed global, one would have to explicitly request it from its environment, e.g.:
self environment: 'Magma' at: #Session
I like this better than aliasing because it shows what's happening when actually using it, not somewhere hidden at the import. It's even less magic :)
I don't like this at all. It's equivalent to a fully qualified class reference, ala VisualWorks Magma.Session or Göran's Magma::Session. Avoiding those is the whole point of this design. Environments should be invisible to the code inside them.
At least that's what I would strive for in an initial implementation. We can add bells and whistles later.
Yes, autoaliasing should certainly wait. As Andreas said, that'll let us see what aliasing strategies work well in practice. We can even hold off on manual aliasing until compiler and tool support is in place. (Not that aliasing is particularly hard to implement.)
That said, I don't want give up the idea of a completely flat namespace from the point of view of application code. That's throwing the baby out with the bathwater. It should appear to Application, that the authors of Seaside and Magma got together and coordinated their class names so that there were no prefixes and no clashes.
Colin