On 4/3/08, Lars Hansen <[EMAIL PROTECTED]> wrote:
>
> package X {
> namespace myns;
>
> class C {
> myns var v = 37;
> }
>
> var x = myns;
> var y = "v";
>
> print((new C).x::[y]);
> }
>
> This does print '37' if compiled with ASC and run through
> the Tamarin VM.
This is like the E4X example in one crucial respect: in both cases,
you're accessing a property of a first-class object. I'm not arguing
against this use of computed names. I don't see any significant
difference between the above and:
var obj = { x: "hello" };
print(obj["x"]);
My claim is simply that...
function foo() {
var x = "hello";
}
... here, x is not a property of a first-class object. x's binding
environment isn't a datum. But:
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.
> > I guess I don't see what use case is satisfied by this
> > feature that isn't already met by the existence of Map.
> >
> > After all, the effect of this feature is to turn lexical
> > environments into (quasi) first class maps, with the peculiar
> > restriction that new name/value pairs cannot be added, though
> > existing ones can be mutated. If a user actually needs that
> > functionality, it wouldn't be difficult to subclass Map to get it.
> >
> > And, yes, I know it's already possible to do this with
> > lexically scoped eval. But why do you want to add another
> > way to do it?
>
>
> Let me turn it around.
>
> The syntax ns::v is in the language, for constant identifier v.
> If E4X is implemented in an implementation (as it will be in
> ActionScript and presumably in Firefox, at least), so is
> ns::[expr]. How would a restriction to require ns to be a
> compile-time constant (in either form) and not a run-time
> value, or a restriction to disallow the latter form in ES4
> but not in E4X, benefit ES4?
>
>From my perspective, it isn't an E4X vs. ES4 distinction; it's a
"looking up a property of a first-class object" vs. "using a local
variable" (or, if you prefer, "looking up a property of an activation
object") distinction. It's not as if this is an uncommon distinction
in programming languages, and the advantage of keeping the distinction
is better static analysis, better performance, more tractable code.
-Jon
>
> --lars
>
>
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
