On Thu, Jun 28, 2012 at 9:48 PM, Chris Cunningham cunningham.cb@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