I think I'm largely in agreement with what you were saying below, but I do have some additional thoughts I added below...
On Jan 23, 2012, at 11:28 AM, Brendan Eich wrote: >> Brendan Eich <mailto:bren...@mozilla.org> >> January 23, 2012 11:08 AM >> >> 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. > > This was prolog, but then I edited too much and may have been unclear: >> >> 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. > > This is about > http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects -- an > accepted proposal in Harmony and extremely likely to be going into ES6. And nothing that I'm currently proposing would take away the ability to use a private name value with square brackets to access properties. However, the current private names object proposal exclusively relies on the use of square brackets. My contention is that there are both usability/readability and future-proofing reasons to provide a different preferred mechanism such as .@ as the primarily way of accessing private name keyed properties instead of requiring use of the obj[privateNameValue] pattern. Also, the square bracket preference also currently shows up in the object literal computed property key proposal so we already have obj[privateNameValue] pattern manifesting itself as new ES6 syntax. > >> 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. Yes, that is exactly my position. > > I don't think everyone agrees on future-proofing for > > http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation Well from my reading, there seems to be at least as much support for Object Model Reformation on this list as there is for guards and we seem to put considerable attention into future proofing for guards. I think extensions to property access including support for private names is an area where we need to think carefully about future implications. > > yet, so I wonder if we'll all agree to add.@ etc. to private_name_objects. > That got into Harmony by avoiding new syntax. We do not want to go in a > circle here (rather, a progress-making spiral ;-). > I agree, having no syntax helped to get agreement on private_name_objects. But now that people are experimenting with coding patterns using them we are beginning to see the usability and future-proofing problems of exclusively depending upon [ ] access. There may now be a better understanding of how private name objects usage could benefit from some syntactic affordances. Spiraling out from private name objects to include .@ and {@name:etc} seems like an all around win that I would hope we could accomplish without just circling around private names again. It is less clear whether we need .@() or the private declaration but the seem worthwhile to consider has part of the whole private name package. Allen
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
