classes and enumerability
herby at mailbox.sk
Thu Jan 22 17:49:56 PST 2015
Allen Wirfs-Brock wrote:
> On Dec 24, 2014, at 1:49 PM, Kevin Smith wrote:
>> Here is the summary:
>> Total Files Read: 11038
>> Files Containing Explicit 'enumerable: false': 149
>> Occurrences of 'enumerable: false' (and variants): 206
>> I love this kind of analysis - thanks!
>> My interpretation of this data is that non-enumerability isn't
>> important enough to bother with in the vast majority of cases. It
>> *may* still be that non-enumerability is the least-surprise option for
>> class methods, but certainly users don't care enough about the issue
>> currently to bother with typing in "enumerable: false".
>> I'm still concerned about the refactoring hazard argument. I think the
>> idea is that if I change some ES5-style class into an ES6-style class,
>> then I need to have good unit tests already in place to make sure that
>> non-enumerability won't break things. Otherwise, I can't do the refactor.
> Let's drill deeper into this concern...
> There are two parts of dealing with a class-abstraction, the definition
> the class and consuming instances of the class. Let's look at the
> enumerability impact on both of those.
> Class definition: In an ES5-level class abstraction library, changing
> the enumerability of methods might have an impact on class creation, if
> the attraction library does something like method copying using for-in.
> However, what we are talking about is converting from an ad hoc (and
> possibly library provided) ES5 class abstraction to using actual ES6
> class definition. Class definitions don't depend upon reflection of
> properties to actually create the class. So, I don't think we have
> anything to worry about on the class definition side. Enumerability of
> properties is irrelevant.
> Class consumption: It pretty much comes down to whether or not consumers
> of class instances in ES5 use for-in with or without hasOwnProperty
> filters to enumerate the properties of class instances. If their ES5
> code uses hasOwnProperty to filter out methods, then the fact that ES6
> methods are non-enumerable will make no difference. On the other hand,
> if consumers of these ES5 class instances are doing for-in enumerations
> and want to see inherited methods then there would be an issue. But,
> other than for meta programming, it hard to imagine why they would
> actually want tfor-in to see any methods.
> Some folks at Auburn University have been studying a large corpus of
> On of the things they've look at is use of for-in and hasOwnProperty.
> Take a look at the data shown on that page for for-in usage and read
> sections X and XI in the accompany paper.
> Personally, I have always believed we are going down the wrong path by
> switching (from the original max-in class design) to making methods
> defined within a class definition enumerable.
Yes, please, if possible, go back to non-enum methods. I was writing at
that time as well, but things ended up enumerable. I even cited a
real-world example (Amber objects used in jQuery API as options
objects), where enum methods broke the functionality, but non-enum
methods allowed things to work.
> The only real model of class-like abstractions that has always and
> universally been a part of JS is the model that the built-in
> constructors consistently follow. The ES6 class definition model was
> intended to exactly mirror that built-in model. My vision for it was
> that future JS programmers should never need to worry about whether a
> "class" was provided by a built-in or from a library or was a local part
> of the application, because they all worked the same.
> By make class defined methods enumerable, we parted from that simple
> vision and instead seem to follow the remediation path that current and
> legacy JS programmers had to follow because the language did not give
> them the capabilities they need to define classes just like the
> built-ins. We're tinking too much about the past and not enough about
> the future.
More information about the es-discuss