noone? JSLint doesn't even let you write a for/in loop if you don't have
`obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
properties (included methods from old classes/ahem prototypes) reassigned
everywhere.
If you deal with data objects and dictionaries yuo'll always have a flat
structure, right? If you don't care about properties descriptors (getters
and setters) you can always use a for/in
```
function flatEnumerables(a) {
for (var c, k, i = 1; i < arguments.length; i++) {
for (k in (c = arguments[i])) a[k] = c[k];
}
return a;
}
```
This would do what you are looking for (which is the first time I
personally read/hear about somebody wanting `Object.assign` to behave like
a for/in)
Would that work?
Best Regards
On Fri, Feb 27, 2015 at 12:56 PM, Andri Möll <[email protected]> wrote:
> 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 <http://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
>> <https://en.wikipedia.org/wiki/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
>> <https://en.wikipedia.org/wiki/Liskov_substitution_principle>.
>>
>> Andri
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
