I would leave Object.keys out of the "problem" since inherited properties
would be ignored regardless not being "own"

It seems to me that reasons are ... that Object.mixin, which was not only
checking enumerable properties but all own, would have solved the extend
example with the prototype but thanks for that, I was not thinking about a
prototype itself to mixin properties.

I would re-think this once Object.mixin will be in again, if ever

Best Regards


On Sat, Jan 11, 2014 at 10:52 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:

>
> On Jan 11, 2014, at 9:57 AM, Andrea Giammarchi wrote:
>
> > Thanks Allen, makes sense ... but still no example where enumerability
> of properties and method defined in a "class" prototype is useful for ...
> something I cannot imagine right now.
> >
> > Anything?
>
> Examples that were mentioned in the discussion that lead to the change
> include abstraction meta methods such as extend or mixin that exist in the
> wild.  These were created in an world where everything that was user
> defined was enumerable (at least by default).
>
> This might be particularly problematic if concise methods in object
> literals are non-enumerable:
>
> $.extend( obj, {
>     foo () {},
>     bar () {},
>     baz: function () {}
> });
>
> it would be surprising if after this call obj only acquired a baz
> property.  (assuming that extend is implemented using for-in or
> Object.keys).
>
> It might be less surprising if we had
>
> class Extension {
>     foo () {}
>     bar () {}
> };
>
> $.extend(obj, Extension.prototype);
>
> but consider if that code had originally been:
>
> function Extension() {}
> Extension.prototype.foo = function () {};
> Extension.prototype.bar = function () {};
>
> $.extend(obj, Extension.prototype);
>
> and somebody "cleaned up" the code by via an ES6 class declaration.
>  Surprise, things break...
>
> Allen
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140111/8107caec/attachment-0001.html>

I would leave `Object.keys` out of the "problem" since inherited properties
would be ignored regardless not being "own"

It seems to me that reasons are ... that `Object.mixin`, which was not only
checking enumerable properties but all own, would have solved the extend
example with the prototype but thanks for that, I was not thinking about a
prototype itself to mixin properties.

I would re-think this once `Object.mixin` will be in again, if ever