Allen Wirfs-Brock <mailto:[email protected]>
January 22, 2012 4:31 PM
I personally have come to the conclusions that
obj.@foo
would be a better than
obj[foo]
for accessing a property of obj that is keyed by the private name that
is the value of the foo binding.
My impression, is that a number of other participants in these
discussion share this opinion. These are various reasons for this
preference, including pleasantness, experience from CoffeeScript and a
desire (rationalize in
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation )
to strongly distinguish routine structural property access from
dynamically computed data key accesses.
If we require only private name objects on the right of @, then there's
another benefit: no misspelled references to public name where a private
one is required. @ means private, not computed.
Regardless of whether this proposal flies we could consider supporting:
private foo,bar;
as a short hand for:
//assume already done: import name as "@names";
const foo=name.create(), bar=name.create();
I think this would be a desirable addition, but I don't want it to be
a make or break issue for the .@ proposal.
I'm game. Without it the Name.create() overhead is onerous.
There are a couple of decision that still need to make for this proposal:
1) should .@ member access and @ object literal property definitions
permit he property key to be any toString-able value and not just
private name values? The current plan of record does not require a
private name value in the analogous contexts.
I'm slightly inclined towards requiring private name values, but would
be happy either way.
As noted above, I'm inclined toward requiring private name objects on
the right of @.
2) elimination of arbitrary expression as direct keys in object
literal property definitions:
The current "computed property keys" proposals allows things like:
for (var n=0;n<10;) {
a.push( {
["prop"+n]: n++
});
}
Do we really need to support this sort of computed property name
definition?
Not obviously at this point. We might want [] and @ but we can certainly
defer [] if we do include @ for private names.
3) should @foo as a primary expression be interpreted as this.@foo
I think it should, but note that this means that
const foo = name.create();
let obj = {
@foo: @foo
};
would mean the same as:
const foo = name.create();
let obj = {
@foo: this.@foo /key and value probably different values
};
rather than:
const foo = name.create();
let obj = {
@foo: foo //key and value are the same value
};
This might be a source of confusion for some JS programmers.
It's not different from let obj = {foo: foo} which uses foo two
different ways. We agreed on the shorthand from object destructuring
being necessary (due to the cover grammar technique we are using --
"Supplemental Syntax") and sometimes desirable, e.g.
function Point(x, y) {
return {x, y};
}
So I do not think @foo meaning something different in a property name
context in an object literal from what it means in an expression is
either new or necessarily confusing. In both the @ and @-free cases, the
property name means something different from the expression form.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
