classes and enumerability
jmar777 at gmail.com
Wed Dec 24 15:05:36 PST 2014
Props to Rick for bringing some analytical rigor into the discussion.
Unfortunately all I can provide in response is more anecdotal and
opinion-based, but, nonetheless, here's how I would counter that:
First, people are lazy, and programmers are people. Seeing a lot of
non-non-enumerable class methods is, IMO, more indicative of the path of
least resistance, not an indicator of calculated, intended behavior.
Second, to quote Kevin from earlier,
If we want to preserve any kind of conceptual integrity for enumerability,
> then enumerability must indicate that the property is a data element within
> a data structure.
A thousand times, this. Properties are state, methods are behavior; this is
just OOP 101 (right?). And I don't see any compelling arguments being made
for enumerating the behavior of an object.
I hate relying on anecdotes, but for all the times I've used ES5-style
"classes", I have always ended up creating enumerable methods simply
because that's the default behavior. I have never, *ever*, done this as a
design decision, and I'd wager (since I have the luxury of no data to prove
or disprove this) that that's a majority position.
On Wed, Dec 24, 2014 at 4:56 PM, Rick Waldron <waldron.rick at gmail.com>
> On Wed Dec 24 2014 at 4:49:36 PM Kevin Smith <zenparsing at gmail.com> 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!
> I was actually inspired by a similar report you created for the list in
> the past.
>> My interpretation of this data is that non-enumerability isn't important
>> enough to bother with in the vast majority of cases.
> Yes, this was my interpretation as well.
>> 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.
> Agreed: this has also been my main argument when the subject has come up
> in the past.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss