On 29.06.2012, at 08:57, Colin Putney wrote:

> On Thu, Jun 28, 2012 at 9:48 PM, Chris Cunningham
> <cunningham.cb at gmail.com> wrote:
>> Well, maybe.  If I understand this right, then when you alias a class,
>> you refer to the alias in the code that is loaded later.  If, however,
>> a class was left unaliased originally (in an import) and was then
>> referenced in the code depending on that import, but later a NEW
>> environment import was introduced with the same class, then if the new
>> importer automatically aliased both of these, the code wouldn't know
>> which one to use.  Which would be unfortunate.
> 
> First and foremost, auto-aliasing would have to be optional. There's
> always the escape hatch of being able to be explicit about everything,
> and get exactly what you want.
> 
> Second, you're talking about two different situations here. One is
> where you're setting up a new environment before it contains any code.
> In that case, you have to create the environment that the code expects
> to see—either code that's already written or the code you're about to
> write. Auto-aliasing provides an reasonable convention that handles
> that case well.
> 
> The other situation is where you add an import to an environment that
> already has code in it, introducing a name clash. There are three
> possible options:
> 
> 1. Create an alias for the binding being imported. We know that the
> code already in the environment doesn't refer to it, so we just give
> it a new name and we're in good shape.
> 
> 2. Create an alias for the existing binding. It requires updating the
> existing code to use the new name. If we have the RB installed, that's
> easy; if not, we can at least bring up a browser with all the
> references to the old name so the user can find them easily.
> 
> 3. Alias both bindings. This gets us to where we'd have been if we'd
> done the import before any code was written. Again it requires
> updating all the existing references.

Or, do nothing at all. The new binding would simply be shadowed.

> We could use auto-aliasing only with empty environments, or have a
> (configurable?) policy for handling name clashes, or just ask the user
> what to do. It doesn't have to be decided now; we'll cross that bridge
> when we get to it.
> 
>> In your Seaside / Magma example, could you leave one Session just as
>> Session, and have the other aliased?
> 
> Sure.
> 
>> 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.
> 
> No. Auto aliasing would happen a namespace is being imported into an
> environment, not when code is being loaded. The idea is to resolve all
> ambiguities when constructing the environment, so that the compiler
> and dev tools can deal with a simple, one-to-one mapping from names to
> classes.
> 
> Colin

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?

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 :)

At least that's what I would strive for in an initial implementation. We can add bells and whistles later.

- Bert -