On Fri, Jun 29, 2012 at 3:32 AM, Bert Freudenberg <bert at 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