> They, er, sort of aren't. One big deal is that you can't `JSON.stringify()` > them, because that ignores inherited properties.
Indeed, I too think JSON.stringify is poorly designed in that respect, especially because, adding insult to injury, inheritance _is_ considered when searching for toJSON. As I said, inconsistent as hell. :-) Those of us, and apparently you included, accept the delete-freeze nuances. People who find copying sufficient, can carry on — inheritance won't affect them. > `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 Reasonable approach to stdlib design. Except this cowpath isn’t paved the way cows walked: Both jQuery.extend _and_ Underscore.extend do consider inheritance. And if the world’s most popular JS library has taken inheritance into account for at least 7 years now (that was the last time I tried to prefix everything with hasOwnProperty), where’s the problem? On Feb 27, 2015, at 16:34, Andreas Rossberg <[email protected]> wrote: > The fragile base class problem is one. That’s a problem of the caller, not the callee, the user of Object.assign. If I decide to use inheritance, that’s my risk. And because a mutable Object.prototype is every object’s ancestor anyway, ignoring intermediary inheritance in Object.assign doesn’t fix anything. > 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): Thanks! I didn’t get much out of it, sadly. I see some vague references to “people do this” and “community does that”, which translates to “people I agree with” and “my community”. The worrying about `Object.prototype.hostile = true` is also a fool’s errand, because every object inherits from Object.prototype and every person uses the dot-operator to read values. Every obj.hostile returns true no matter how many times you run it through Object.assign. That is security theatre. I did find an argument I haven’t addressed directly: because a future record type won’t support inheriting from, it follows that neither should it be supported for regular objects. Well, no. That’s a non sequitur. Inheritance is an implementation detail. A callee must not care how properties of a pre-agreed upon interface are implemented. Object.assign even agrees to half of it — it doesn’t care whether a property is plain or implemented as a getter. Now it just needs to iterate over inheritance and all’s dandy. A. On Feb 27, 2015, at 16:21, Leon Arnott <[email protected]> wrote: > 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]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
