On 4/3/08, liorean <[EMAIL PROTECTED]> wrote:
> On 04/04/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> >
> > function foo(name) {
> > ...
> > return null::[name];
> > }
> >
> > ... treats the environment as if it were a datum. I know that in the
> > ES3 spec all bindings are referred to as properties of objects, but
> > activation objects are only notional entities. The current ES4
> > proposal seems to raise their status by giving programmers a simple
> > mechanism to (practically) reify them.
>
>
> Except you can't actually make the activation object a first class
> object. The null namespace (or any other namespace) is orthogonal to
> the activation object - you can now look up local variables
> dynamically instead of just statically, but the scope still cannot be
> leaked out of the function in any way.
Right, hence the 'practically.' There's no meaningful difference,
though; the function simply acts as a proxy for the environment. I
mean, what important difference is there (as far as the current
discussion is concerned) between:
var map = new PeculiarMap(["foo", "bar", "baz"]);
... where PeculiarMap is a subclass of Map that maintains a constant
set of keys, but allows those keys to be associated with new values,
and:
var map = (function() {
var foo, bar, baz;
return {
get: function(name) {
return null::[name];
},
set: function(name, value) {
null::[name] = value;
}
};
})();
The fact that you can't pass around the activation object itself
doesn't seem terribly significant. What would you be able to do if it
were a real first-class object that you can't do here?
>
> The only notable change is that you now have a method of making
> dynamic lookup of the local variables in a scope instead of only
> static lookup. The method of doing so is considerably better than
> locally scoped eval because it's restricted to doing just that and
> nothing more.
That's fine, but why would you want to do that, at all? My point is
this: there's an obvious downside to this kind of lookup (inhibiting
static analysis and all that), but there's no obvious upside to it.
I suppose the argument goes: if the choice is between calling eval to
perform this kind of lookup or using ns::[expr], it's better to use
ns::[expr]. I won't argue with that, but it's a false dilemma. You
could just use an actual data structure.
eval has a real use: runtime code generation. (This does not require
dynamically scoped eval, but that's beside the point here.) Dynamic
lookup of activation object "properties," however, doesn't seem...
useful. (I certainly could be wrong about this, but I can't think of
a compelling use case. And, again, this does *not* apply to dynamic
lookup of first-class object properties, which is obviously useful.)
The point being: ES3 programmers who are using eval to perform
dynamic lookup of activation object properties don't need a better
mechanism to do the same thing, because what they're doing doesn't
make sense to begin with.
-Jon
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
