andrea.giammarchi at gmail.com
Sun Jan 12 20:57:51 PST 2014
Recap: it seems we agree classes properties and methods should not show up
in a for/in ... which I believe is the eldorado JS developers looked for
since ever, hating that only native classes had that privilege ... so, once
again why on earth classes methods and properties show up in a for/in since
nobody ever wanted that?
I agree that the method definition for the object should not be affected,
but it seems to me we mixed up two different things: a) the object method
definition, and we all agree here b) inherited classes properties and
methods ... and I guess we all dream about not disturbing/enumerable
properties and/or methods in a for/in since that is not desired and forces
indeed developers to think they need .hasOwnProperty() check all over which
is an anti-pattern if you ask me, and indeed my class utility defines
everything in the class as **non-enumerable**.
Thanks for clarifications
On Sun, Jan 12, 2014 at 8:45 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:
> Rick, what you wrote has _nothing_ to do with inheritance, right? So why
> should "classes" methods be part of a for/in of an instance, which is not
> what you wrote, again? Thanks
> On Sun, Jan 12, 2014 at 8:21 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
>> On Sat, Jan 11, 2014 at 12:57 PM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> 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.
>>> Again, that was never the argument, but simply a by-product of making
>> concise method definitions behave the same way as function expression
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss