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 < [email protected]> 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 <[email protected]>wrote: > >> >> >> >> On Sat, Jan 11, 2014 at 12:57 PM, Andrea Giammarchi < >> [email protected]> 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 >> definitions. >> >> Rick >> >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
