> You are talking about "flatting" all properties, which is an undesired > overhead.
Umm, Object.assign is as it is because of performance? I don’t think it is nor is that a good reason. Every property access in JavaScript takes inheritance into account and there are thousands more than a Object.assign call here and there. > But what's bugging me every time more, is that somebody had a very bad idea > to spread `Object.assign` as something good for inheritance or object cloning. > > Where does this come from? `Object.assign` retrieves properties and ignore > getters and setters, is the last tool you want to use as substitution > principle because it breaks. Ignores getters? You mean merely reads them? That’s not ignoring. Getters are an implementation detail of an interface. Prototypes aren't only useful for sharing behavior. They’re just as useful for data objects and value types. Nothing breaks when you clone or assign them around. Object.assign just read properties from one object and assign them to another. Something you used to do by hand. It’s just shorter to type assign(A, B) than type all properties of B out manually. If it’s _not_ meant to be the function-equivalent of `for (var key in source) target[key] = source[key]` then that’s too bad as my money is on it’s going to be used as such. I definitely want to use it for that. > But what's bugging me every time more, is that somebody had a very bad idea > to spread `Object.assign` as something good for inheritance or object cloning. > Are you dealing with prototypes and `Object.assign` ? You gonna have way more > problems than a missed flattered structure. > Can you explain what is your goal ? Wouldn't this work? Inheritance? Inheritance is an implementation detail. A function receiving an object must not care about its inheritance tree as long as it fulfills the required interface. That’s what the LSP says as well. Even though JavaScript has no explicit concept of interfaces or types, they’re implicit in any function call. My goal is to save people from having to think every time they call a function whether this 3rd party function ignores inherited properties or not. If the callee uses Object.assign, it strips them out, if not, the dot-operator takes it into account. Surely no-one’s expecting everyone to prefix _every_ obj.name use with hasOwn: `obj.hasOwnProperty(“name”) && obj.name`. Why do it in Object.assigns then is beyond me. Inconsistent and uncalled for. A. On Feb 27, 2015, at 14:24, Andrea Giammarchi <[email protected]> wrote: > You are talking about "flatting" all properties, which is an undesired > overhead. > > ```js > > var b = Object.create( > Object.getPrototypeOf(a) > ); > > Object.assign(b, a); > > ``` > > But what's bugging me every time more, is that somebody had a very bad idea > to spread `Object.assign` as something good for inheritance or object cloning. > > Where does this come from? `Object.assign` retrieves properties and ignore > getters and setters, is the last tool you want to use as substitution > principle because it breaks. > > `Object.assign` is good only to define enumerable, writable, and configurable > properties, like configuration or setup objects. > > Are you dealing with prototypes and `Object.assign` ? You gonna have way more > problems than a missed flattered structure. > > Can you explain what is your goal ? Wouldn't this work? > > ```js > > var a = {}; // or anything else > > var b = Object.create( > Object.getPrototypeOf(a) > ); > > Object.getOwnPropertyNames(a).forEach(function (k) { > Object.defineProperty(b, k, Object.getOwnPropertyDescriptor(a, k)); > }); > > ``` > > > Best Regards > > > > On Fri, Feb 27, 2015 at 11:52 AM, Andri Möll <[email protected]> wrote: > Hello, > > Why does Object.assign ignore inherited enumerable properties? > What is the problem to which ignoring inherited properties is the solution to? > > All I can see is that it prevents a useful use of inheritance. The Liskov > substitution principle was mentioned 27 years ago in ’87. Why is > Object.assign breaking it? > > - Everyone who’s messing with Object.prototype has to do it an non-enumerable > style anyway. > - Most uses of Object.assign will likely be for objects with a finite number > of keys. Those form specific and implicit types from which people are likely > to read with the dot-operator. That takes inheritance into account anyway. > > I don’t get the agenda to mess with object inheritance. If one wants methods > to only be in the parent and data on the child (so Object.assign would only > copy data), use a classical language. In a delegation-prototypal language one > should be able to inherit freely because of LSP. > > Andri > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
