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.

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