shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich brendan at mozilla.org
Mon Jan 23 11:08:23 PST 2012


> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> January 23, 2012 11:01 AM
>
> Below...
> Brendan Eich <brendan at mozilla.org> wrote:
> > Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> > January 23, 2012 8:43 AM
> > On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote:
> >
> ?..
> >
> > const getIterator = Iterator.getIterator;
> > myCoolObject.prototype. at getIterator = function() {...}
>
> Why wouldn't myCoolObject.prototype[iterator.getIterator] work?
>
> /be
>
> It would, for now.  But, I think you gave the reason for avoiding this 
> pattern in another reply. If we ever want to adopt my Reformed Object 
> Model proposal then we should avoid using [ ] for private name 
> property access.  lt would actually still work fine for objects with 
> default [ ] behavior but not for collection objects that redefine [ ] 
> access.
>
> Before encouraging a new pattern like obj[Iterator.GetIterator] we 
> should think about its future-proofing implicationa.

We run into this kind of trade-off all the time, but the fact is that 
right now, dot and brackets are equivalent for properties named by 
strings that match the IdentifierName lexical production. This isn't the 
case for private names, of course -- by design: no string equivalent so 
no dot.

However it does not follow that a first-class private name object value 
cannot be used in square brackets to access a property it names. If we 
must future-proof, then it follows that .@ and even .@() must be part of 
private name objects. If everyone agrees, then we have a decision to make.

/be


More information about the es-discuss mailing list