On Fri, Feb 27, 2015 at 10:56 PM, Andri Möll <[email protected]> wrote: > Prototypes aren't only useful for sharing behavior. They’re just as useful for data objects and value types.
They, er, sort of aren't. One big deal is that you can't `JSON.stringify()` them, because that ignores inherited properties. Additionally: you can't `delete` properties from them reliably because you don't know whether they're inherited. You can't `Object.freeze()` them to guarantee their property interface will never be modified afterward, because the prototypes could still be altered (this could be construed as a feature, but I think it too badly wounds the "guarantee" that Object.freeze offers). You also can't `Object.freeze()` the first prototype, because then its properties can't be easily overridden on its inheritors due to the override "bug". The main use-case for `Object.create()`ing data objects seems to be virtual duplication of the properties. Suggestion: switch to exclusively using actual duplication via `Object.assign()` whenever possible. Granted, I actually do have a personal project that uses the prototype chain to make a data structure, but I don't consider its use to be common or robust enough to be standardised, yet. ... `Object.assign` was designed specifically to "pave a cowpath" - that is, to take a very common third-party function and exactly replicate its semantics in the standard, as a drop-in replacement in future projects. (`Object.create` and `Function.prototype.bind` arose from a similar upbringing.) The semantics it replicates are `jQuery.extend`, PrototypeJS's `Object.extend` and similar `.extend` methods, which only copy enumerable own non-symbol properties. I don't quite like it, myself, because I think the 'non-symbol' restriction is a bit of a dated decision from back when symbols were "private members" instead of the more general unique property identifiers they are now - but it's still my most commonly used ES6-shim method. If you're interested in a rough idea of where TC39 stands on data object copying, see [these notes about object rest destructuring]( https://github.com/rwaldron/tc39-notes/blob/b1af70ec299e996a9f1e2e34746269fbbb835d7e/es6/2014-09/sept-25.md#58-object-rest-destructuring-and-spread-properties ): >MM: In ES3, assumption is there's all sorts of gunk on Object.prototype because no way to get rid of it. Reason it was restricted to own-ness was because there was a desire to not iterate stuff on Object.prototype > >YK: There's a notion of copying today that means "enum, own" > >AWB: Notions in JS today are diff from notions 5 years ago and 5 years from now > >MM: We can't accomodate legacy in this way forever. We're in a history dependent trap, we should make this (enumerable + own)?[verify]
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
