True. I was thinking shallow clone:

```js
var copy = Object.assign({ __proto__: obj.__proto__ }, obj);
```

But `Object.mixin()` (or `Object.define()`, I thought the case for re-renaming it was convincing) is probably a better match here.

Will `keys()`, `values()` and `entries()` from module "@dict" ignore non-enumerable properties, too?

Axel

On Jan 12, 2014, at 6:28 , Brendan Eich <brendan at mozilla.com> wrote:

> Brendan Eich wrote:
>>> I can only think of cases (including Claude Pache’s pro-enumerability example) where I would want to copy *all* own properties.
>> 
>> Why do you want an array's .length to be copied? 
> 
> Or in Claude's example, why should a non-enumerable _parent be copied?
> 
> Claude's words about the advantage of non-enumerable _parent *not* being copied were pretty clear. He was not advocating *all* own properties.
> 
> http://esdiscuss.org/topic/enumerability#content-2

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140113/49d2ac23/attachment.html>

> Brendan Eich wrote:
>>> I can only think of cases (including Claude Pache’s pro-enumerability example) where I would want to copy *all* own properties.
>> 
>> Why do you want an array's .length to be copied? 
> 
> Or in Claude's example, why should a non-enumerable _parent be copied?
> 
> Claude's words about the advantage of non-enumerable _parent *not* being copied were pretty clear. He was not advocating *all* own properties.
> 
> http://esdiscuss.org/topic/enumerability#content-2

True. I was thinking shallow clone:

```js
var copy = Object.assign({ __proto__: obj.__proto__ }, obj);
```

But `Object.mixin()` (or `Object.define()`, I thought the case for re-renaming it was convincing) is probably a better match here.

Will `keys()`, `values()` and `entries()` from module "@dict" ignore non-enumerable properties, too?