On 2010-12-17 01:24, David Herman wrote: > Mark Miller wrote: >> Ok, I open it for discussion. Given soft fields, why do we need private >> names? > > I believe that the syntax is a big part of the private names proposal. It's > key to the usability: in my view, the proposal adds 1) a new abstraction to > the object model for private property keys and 2) a new declarative > abstraction to the surface language for creating these properties.
I don't like the private names syntax. I think it obscures more than it helps usability, and losing the x["id"] === x.id equivalence is a significant loss. As Mark points out, though, that syntax can be supported with either proposal. The private names proposal is more entangled with syntactic changes, but that's a bug, not a feature. > In fairness, I think the apples-to-apples comparison you can make between > the two proposals is the object model. On that score, I think the private > names approach is simpler: it just starts where it wants to end up (private > names are in the object, with an encapsulated key), whereas the soft fields > approach takes a circuitous route to get there (soft fields are > semantically a side table, specified via reference implementation, but > optimizable by storing in the object). The private names approach is not simpler. It's strictly more complicated for the same functionality. You can see that just by comparing the two proposals: in http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields the specification consists entirely of the given code for the SoftField abstraction. In practice you'd also add a bit of non-normative rationale concerning how soft fields can be efficiently implemented, but that's it. In http://wiki.ecmascript.org/doku.php?id=strawman:private_names (even exlcuding the syntactic changes, to give a fairer comparison), we can see a very significant amount of additional language mechanism, including: - a new primitive type, with behaviour distinct from any other type. This requires changes, not just to 'typeof' as the strawman page acknowledges, but to every other abstract operation in the spec that can take an arbitrary value. (Defining these values to be objects would simplify this to some extent, but if you look at how much verbiage each [Class] of objects takes to specify in ES5, possibly not by much.) - quite extensive changes to the behaviour of property lookup and EnvironmentRecords. (The strawman is quite naive in suggesting that only 11.2.1 step 6 needs to be changed here.) - changes to [[Put]] (for arrays and other objects) and to object literal initialization; also checking of all uses of [[DefineOwnProperty]] that can bypass [[Put]]. - changes to a large number of APIs on Object.prototype and Object, the 'in' operator, JSON.stringify, and probably others. None of these additional mechanisms and spec changes are needed in the soft field approach. In addition, the proposal acknowledges that it only provides weak encapsulation, because of reflective operations accessing private properties. It justifies this in terms of the utility of "monkey patching", but this seems like a weak argument; it is not at all clear that monkey patching of private properties is needed. Scripts that did that would necessarily be violating abstraction boundaries and depending on implementation details of the code they are patching, which tends to create forward-compatibility problems. (This is sometimes true of scripts that monkey-patch public properties. I'm not a fan of monkey patching in general, but I think it is particularly problematic for private properties.) There is some handwaving about the possibility of sandboxing environments being able to work around this deficiency, but the details have not been thought through; in practice I suspect this would be difficult and error- prone. In general, I disagree with the premise that the best way to *specify* a language feature is to "start where it wants to end up", i.e. to directly specify the programmer's view of it. Of course the programmer's view needs to be considered in the design, but as far as specification is concerned, if a high-level feature cannot be specified by a fairly simple desugaring to lower-level features, then it's probably not a good feature. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
