)
chose to align class prototype method enumerability with ECMA-262 core
language built-in method enumerability and clearly-voiced developer
expectations, against the old DOM enumerable-method norm, with the
intention to bend WebIDL default that way where possible and provide
decorator-based
Brendan Eich wrote:
Please drop the crappy us vs. them talk. If you read this thread,
and others on esdiscuss.org, you can see TC39 did not keep ignoring
feedback. Yeesh!
In case it is not clear: Andrea is not on TC39, not us or them in
your dichotomy, and while I agree he disregarded (if
Worth noting: DOM classes won't be the only objects a JavaScript user
interacts with that have enumerable methods. Virtually 100% of class
libraries in JavaScript, including ones created after ES5, create classes
with enumerable methods.
I don't think that this change has a prayer of making
Andrea Giammarchi wrote:
Do we agree this class decision was a good one? Perfect, then let's
move on to another thread and discuss how things could be better from
both worlds point of view in the future.
I'm not sure why you replied to me, since I (and everyone on TC39) has
agreed to make
-discuss@mozilla.org
Subject: Re: classes and enumerability
Andrea Giammarchi wrote:
Do we agree this class decision was a good one? Perfect, then let's
move on to another thread and discuss how things could be better from
both worlds point of view in the future.
I'm not sure why you replied
I didn't mean to disrespect anybody work here, I am just personally a bit
tired of TC39 decisions that, after being already made and widely discussed
in the same thread, are complained/disregarded regardless everyone agreed
already on an official meeting.
I am not TC39 and not even close to
On Fri, Jan 30, 2015 at 7:44 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Developers have to understand they cannot `new HTMLDivElement()` anyway and
they cannot extend WebIDL interfaces in JS world neither.
That will change.
bz and others have been working on bridging the gap for
for everything in JS land instead of
adopting above pattern in case it does not want to go enumerable?
And again, who actually wants that enumerability and why?
Best Regards
On Fri, Jan 30, 2015 at 10:52 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Jan 30, 2015 at 7:44 AM, Andrea
On 1/30/15 1:44 AM, Andrea Giammarchi wrote:
Developers have to understand they cannot `new HTMLDivElement()` anyway
That will change.
I am not sure why you see this misalignment that has always been there a
problem just now
I've seen it as a problem for a while now, as a cursory look at
On 1/30/15 7:56 AM, Andrea Giammarchi wrote:
this will change too ?
`NodeList.prototype.propertyIsEnumerable('length')`
Changing that is what we're talking about, yes.
WebIDL is full of inconsistencies compared with JS world and that,
talking about backward compatibility, shouldn't change.
in ES6 is that these have never
even landed officially in JS, WebIDL did already, and as ES3 prototypal
like inheritance work in ES6 regardless, anything that requires
enumerability can simply use that inheritance style.
New things could use new class ... I think nobody would be surprised
On 1/30/15 8:43 AM, Andrea Giammarchi wrote:
The reason classes could have been fixed in ES6 is that these have never
even landed officially in JS, WebIDL did already
WebIDL did nothing of the sort so far. What we have is various legacy
behaviors, some of which WebIDL codified. _That_'s
Announcement: ES6 class method syntax makes a non-enumerable property of
the method's name on the class prototype. That is all. :-)
/be
Brendan Eich wrote:
Herby Vojčík wrote:
Personally, I have always believed we are going down the wrong path by
switching (from the original max-in class
\o/
On Thu, Jan 29, 2015 at 2:55 PM, Brendan Eich bren...@mozilla.org wrote:
Announcement: ES6 class method syntax makes a non-enumerable property of
the method's name on the class prototype. That is all. :-)
/be
Brendan Eich wrote:
Herby Vojčík wrote:
Personally, I have always
Very glad to see this happen!
Yehuda Katz
(ph) 718.877.1325
On Thu, Jan 29, 2015 at 11:55 AM, Brendan Eich bren...@mozilla.org wrote:
Announcement: ES6 class method syntax makes a non-enumerable property of
the method's name on the class prototype. That is all. :-)
/be
Brendan Eich
On 1/29/15 4:36 PM, Yehuda Katz wrote:
Are you asking what to do about the fact that existing WebIDL classes
produce enumerable properties that probably can't be made non-enumerable
without breaking the web?
I think the following things need to be decided:
1) What should the behavior be for
On 1/29/15 4:21 PM, Brendan Eich wrote:
I was hoping someone deeper into WebIDL (and with more time for it than
I have right now :-P) would do that.
I missed the part of the first-day TC39 meeting where this was resolved,
so I hope someone who was there can speak to the WebIDL plan, if any.
On Thu, Jan 29, 2015 at 1:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/29/15 4:21 PM, Brendan Eich wrote:
I was hoping someone deeper into WebIDL (and with more time for it than
I have right now :-P) would do that.
I missed the part of the first-day TC39 meeting where this was
On 1/29/15 4:54 PM, Yehuda Katz wrote:
To be completely clear, there's nothing that requires DOM to define its
objects as using precisely the semantics of ES6 classes
Sure. There is nothing that requires the DOM to define its objects in
any particular way at all. As observed in actual
Yehuda Katz
(ph) 718.877.1325
On Thu, Jan 29, 2015 at 1:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/29/15 4:36 PM, Yehuda Katz wrote:
Are you asking what to do about the fact that existing WebIDL classes
produce enumerable properties that probably can't be made non-enumerable
without
Boris Zbarsky wrote:
On 1/29/15 2:55 PM, Brendan Eich wrote:
Announcement: ES6 class method syntax makes a non-enumerable property of
the method's name on the class prototype. That is all. :-)
Please post to public-script-coord with the proposed plan for web idl.
I was hoping someone deeper
awesome news!!! thanks for sharing and also curious to know about other non
method properties, including statics.
Just to be aligned, not to complain, I have not a strong opinion except
eventually for getters, that should be non enumerable too for consistency
with what we have natively (e.g.
My sense, from the informal discussions about this at the TC39 meeting, is that
most of us would hope that new WebIDL abstractions follow the ES6 class
conventions and that existing WebIDL, because of legacy constrants abstraction
are likely not to migrate to the ES6 class conventions.
On 1/29/15 5:43 PM, Allen Wirfs-Brock wrote:
My sense, from the informal discussions about this at the TC39 meeting, is that
most of us would hope that new WebIDL abstractions follow the ES6 class
conventions and that existing WebIDL, because of legacy constrants abstraction
are likely not
Developers have to understand they cannot `new HTMLDivElement()` anyway and
they cannot extend WebIDL interfaces in JS world neither.
I am not sure why you see this misalignment that has always been there a
problem just now, but also I am not sure I understand why this wouldn't be
equivalent:
On Thu, Jan 29, 2015 at 6:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/29/15 9:41 PM, Yehuda Katz wrote:
I've personally written a lot of code that enumerates over the
properties of an element or other DOM object for some reason or other. I
strongly suspect that making existing WebIDL
On Thu, Jan 29, 2015 at 5:51 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/29/15 5:43 PM, Allen Wirfs-Brock wrote:
My sense, from the informal discussions about this at the TC39 meeting,
is that most of us would hope that new WebIDL abstractions follow the ES6
class conventions and that
On 1/29/15 9:41 PM, Yehuda Katz wrote:
I've personally written a lot of code that enumerates over the
properties of an element or other DOM object for some reason or other. I
strongly suspect that making existing WebIDL attributes non-enumerable
would not be web-compatible (nor, or even in the
OK, let's just cc public-script-coord here too. For those just joining
in: the question is whether Web IDL prototype members should be
enumerable given that TC39 just decided that inline-declared methods on
classes are not enumerable in ES6.
On 1/29/15 9:45 PM, Yehuda Katz wrote:
Right,
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
Herby Vojčík wrote:
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
) of
properties defined on prototypes as enumerable: false, but no single
definition would be picked by your script.
--
View this message in context:
http://mozilla.6506.n7.nabble.com/classes-and-enumerability-tp329572p331212.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list
definition would be picked by your script.
--
View this message in context:
http://mozilla.6506.n7.nabble.com/classes-and-enumerability-tp329572p331212.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es
Considered how this thread started and the exact day of the year a common
agreement happened, I believe the following ending would be more than
appropriate:
Ho Ho Ho
___
es-discuss mailing list
es-discuss@mozilla.org
Somehow the thread forked, and I see Kevin Smith already wrote a reply
on the other branch like mine -- sorry about that. But how did the
thread fork?
/be
Brendan Eich wrote:
ES5 has Object static methods for getting all own property names,
enumerable or not. Also walking prototype chain.
Nothing. I forgot about those methods, and Kevin also kindly reminded me.
Thanks for letting me know. :)
On Dec 24, 2014, at 5:22 PM, Brendan Eich bren...@mozilla.org wrote:
ES5 has Object static methods for getting all own property names,
enumerable or not. Also walking prototype chain.
I've replied to Rick privatly by accident but regardless what I've written
there, which is basically agereing with Brendan on the following sentence:
It ain't over till it's over. If we can't tweak ES6 to fix a mistake,
just because process, then we're doing it wrong.
and describe why his
```js
class List extends Array {
itsGoingToBeEnumerable() {
return 'but does it have to and would you expect to?';
}
}
```
That's a good point.
As far as I can tell, the downside risk associated with making class
methods non-enumerable centers around mixins:
- Legacy mixin
Kevin Smith wrote:
I looked through my ES6 code and found a place where I was using
`Object.assign` as an simplistic mixin function.
ES5 introspection APIs are enough, and if you're mixing in from an ES6
class using old code, you face the same non-enumerable-methods surface
that you would
I don't see any risk around mixins for the following reasons:
1. mixins are nowhere in specs so any solution is personal/ad-hoc but ...
2. if you use `Object.assign` you don't do that at class definition
time, you do that eventually after. This possibility will be unchanged, you
can
ES5 introspection APIs are enough, and if you're mixing in from an ES6
class using old code, you face the same non-enumerable-methods surface that
you would with a built-in class.
True, and even more so, I like Andrea's point that mixing in getters and
setters requires ES5 APIs anyway (i.e.
The alternative is to treat enumerability the way ES6 treats holes: pretend it
doesn’t exist:
* Use `Reflect.ownKeys`, `Object.getOwnPropertyNames`,
`Object.getOwnPropertySymbols` instead of `Object.keys`.
* Don’t use the `for-in` loop (an easy one…)
* Change `Object.assign` so
is bigger than the past, would be best?
Put in these terms, I still think that maintaining status quo makes sense.
The future _is_ bigger than the past and this can be addressed via
annotations (maybe even in ES7?).
It seems worthwhile to mention non-enumerability has its own problems:
recall
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
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
-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
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
is that non-enumerability isn't
important enough to bother with in the vast majority of cases.
There's a confounding variable: the pain of ES6s meta-object APIs, in
all respects.
It's probably true that enumerability doesn't matter enough for many
programmers, but the ES5 MOP is painful enough
enough but don't have time and cause to take the trouble.
The trouble is due to the non-default nature of non-enumerability.
Arguing from that past default to (still-future for a little while!) ES6
class's prototype methods being non-enumerable is circular, if you
ignore the foolish-consistency
virtue and a part of human
nature. People are not bothering where they don't know better, or do perhaps
know enough but don't have time and cause to take the trouble. The trouble is
due to the non-default nature of non-enumerability. Arguing from that past
default to (still-future
Caitlin Potter wrote:
Supposing that methods were non-enumerable by default, would accessors be
different, or also non-enumerable by default?
Non-enumerable, to match built-ins (RegExp.prototype has some notable
accessors).
/be
___
es-discuss
check, these same libraries never bothered about getters and
setters inheritance too though (most of them)
Find out that Mr. D talked about enumerability as one of the bad part
people got used to but new comers will always smash their code against
Find out that someone actually bothered about
Boris Zbarsky wrote:
3) Try to make all DOM stuff non-enumerable, dealing with compat
issues by adding [LegacyEnumerableProperties] in the few cases where
they arise. This risks landing us in the same place as #2 depending
on how many interfaces need the annotation, plus compat fallout as we
Axel Rauschmayer wrote:
The alternative is to treat enumerability the way ES6 treats holes:
pretend it doesn’t exist:
That doesn't work, here or for holes. We've actually split APIs with
respect to holes, and this will mean bugs. We did make an intentional
future-trumps-past choice against
-default nature of non-enumerability. Arguing from
that past default to (still-future for a little while!) ES6 class's
prototype methods being non-enumerable is circular, if you ignore the
foolish-consistency argument (which I think we should, but Im not
dismissing here -- just noting that it isn't
Sorry, you can't use small-world reasoning about programming in the
large, especially with JS on the web. for-in proliferated, before
hasOwnProperty appeared in ES3. Even after, the burden was high enough,
per that study Allen cited
but don't have time and cause to take the trouble. The
trouble is due to the non-default nature of non-enumerability. Arguing
from that past default to (still-future for a little while!) ES6 class's
prototype methods being non-enumerable is circular, if you ignore the
foolish-consistency
that
will make again those getters/setters meaningful.
However, to just pass data around, I see if that accessor contains a
sensible info, of course you want it in.
I wonder if this is really the most common case though ... and if we should
make the enumerability desired as such most common case.
We
the properties that
will make again those getters/setters meaningful.
However, to just pass data around, I see if that accessor contains a
sensible info, of course you want it in.
I wonder if this is really the most common case though ... and if we
should make the enumerability desired
properties being enumerable”.
I agree with Andrea here that `hasOwnProperty` has to be taken into
consideration. Especially whether people use `hasOwnProperty` inside “for in”.
Because that’s what enumerability of class syntax will eventually affect.
Nothing else matters if I’m not wrong
enumerability of class syntax will eventually
affect. Nothing else matters if I’m not wrong. (This seems to also be
Allen’s opinion)
2. Allen’s study addressed exactly that.
Especially the ENUMERATION WITH FOR…IN” chapter. And again, epic. :)
The conclusion in the study
Got it, thanks!
On 25 Dec 2014, at 01:26, Brendan Eich bren...@mozilla.org wrote:
Axel Rauschmayer wrote:
The alternative is to treat enumerability the way ES6 treats holes: pretend
it doesn’t exist:
That doesn't work, here or for holes. We've actually split APIs with respect
to holes
enumerable”.
I agree with Andrea here that `hasOwnProperty` has to be taken into
consideration. Especially whether people use `hasOwnProperty` inside “for
in”. Because that’s what enumerability of class syntax will eventually
affect. Nothing else matters if I’m not wrong. (This seems
On 12/24/14 4:22 PM, Brendan Eich wrote:
We aren't going to reverse-Conway the core language built-ins to have
enumerable methods, ever
Sure. Note that this was not one of my three possible listed courses of
action.
-- so I think the right attack is on the quirky DOM.
I think the
Boris Zbarsky wrote:
-- so I think the right attack is on the quirky DOM.
I think the fundamental assumption that the DOM is quirky is broken.
Something is quirky if we want mostly-consistent non-enumerability of
proto-methods/accessors. Either core built-ins, or DOM. Sorry if
quirky
On 12/24/14 9:34 PM, Brendan Eich wrote:
Something is quirky if we want mostly-consistent non-enumerability of
proto-methods/accessors. Either core built-ins, or DOM. Sorry if
quirky sounds pejorative
It sure does at least to me.
Hey, it's me, the JS perpetrator, here :-P.
Yes, I know
On 12/24/14 9:50 PM, Boris Zbarsky wrote:
That's my gut feeling too, esp. if we can de-Conway.
Also relevant here is
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27361 which never really
got a response... I wish the W3C bugzilla had the needinfo feature.
-Boris
Dear Santa,
I wish since ES3 era that properties defined on a prototype are by
default **not** enumerable.
By any chance we can make this happen in ES6 classes?
Or better ... why would anyone expect or want them to be enumerable?
To define a `class` is a very explicit intent, I believe having
On 12/23/14 4:35 PM, Andrea Giammarchi wrote:
Or better ... why would anyone expect or want them to be enumerable?
This is a good question. Note that there is web content that depends on
the current setup wherein stuff on DOM prototypes is enumerable... you
may want to check on why exactly
://github.com/rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2014-01/jan-28.md#concise-methods-and-enumerability
- https://esdiscuss.org/topic/enumerability#content-23
The consistency argument has won every time this conversation is brought
up. There are ways to get what you
-
https://github.com/rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2014-01/jan-28.md#concise-methods-and-enumerability
https://github.com/rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2014-01/jan-28.md#concise-methods-and-enumerability
- https
It ain't over till it's over. If we can't tweak ES6 to fix a mistake,
just because process, then we're doing it wrong. OTOH the bar for any
change, including what is regarded by many (but not all) as a fix, is
very high.
We should take advantage of es-discuss to debate the crucial question,
I would say enumerate through classes' or instances' properties are a strange
use and should be discouraged. I would prefer nothing but instance properties
to be enumerable. To me, it is illogical for methods to be enumerable.
In all the discussions I've observed, the primary argument for
enumerability has been consistency with ES5 prototype conventions. I don't
think I've seen a single argument in favor, though, based on the actual
intrinsic merits of that behaviour.
So, do such arguments exist?
On Dec 23, 2014 11:26
Jeremy Martin wrote:
In all the discussions I've observed, the primary argument for
enumerability has been consistency with ES5 prototype conventions. I
don't think I've seen a single argument in favor, though, based on the
actual intrinsic merits of that behaviour.
Right, hence my tweet
The question is: what should ES6 classes choose as the default? What's the
most useful default, independent of various backward-looking consistencies?
What, if the future is bigger than the past, would be best?
Framed that way, then non-enumerability.
If we want to preserve any kind
that way, then non-enumerability.
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.
Whether enumerability is worth preserving, I don't know.
I'll just throw out mixins
I'll just throw out mixins as a possible reason to keep enumerability.
I don't think enumerability really bears on mixins in ES6, because (for
one) the mixin source could have symbol-named properties. A fully-featured
mixin function will need to use Object.getOwnPropertySymbols, etc
, independent of various backward-looking consistencies?
What, if the future is bigger than the past, would be best?
Framed that way, then non-enumerability.
If we want to preserve any kind of conceptual integrity for enumerability,
then enumerability must indicate that the property is a data
?
What, if the future is bigger than the past, would be best?
Framed that way, then non-enumerability.
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.
Whether
Object.defineProperty could easily do that.
From: curvedm...@gmail.com
Date: Wed, 24 Dec 2014 13:33:24 +0800
Although I guess it’s not very easy to desugar to es5 if there is no way to
enumerate prototype methods/properties. (probably impossible?)
How?
Given that you don’t know the names of the prototype properties and methods
contained (could be deep in the prototype chain) in a object. How do you add
these to another object?
On Dec 24, 2014, at 1:50 PM, Gary Guo nbdd0...@hotmail.com wrote:
Object.defineProperty could easily do
I guess it’s probably a misunderstanding.
I was saying that a feature like lightweight traits is probably impossible to
desugar to es5, if class syntax makes properties and methods non-enum.
On Dec 24, 2014, at 1:50 PM, Gary Guo nbdd0...@hotmail.com wrote:
Object.defineProperty could easily
Given that you don’t know the names of the prototype properties and
methods contained (could be deep in the prototype chain) in a object. How
do you add these to another object?
getOwnPropertyNames, getOwnPropertySymbols, and getPrototypeOf to traverse
the prototype chain.
Oh, forget about those. Thanks. Then problem solved.
non-enum class syntax + trait syntax. This could make prototypal inheritance a
joy to write. :)
On Dec 24, 2014, at 2:02 PM, Kevin Smith zenpars...@gmail.com wrote:
Given that you don’t know the names of the prototype properties and
Although when desugaring to es5, no need to consider symbol properties.
On Dec 24, 2014, at 2:02 PM, Kevin Smith zenpars...@gmail.com wrote:
getPrototypeOf
___
es-discuss mailing list
es-discuss@mozilla.org
On 12/23/14 8:49 PM, Brendan Eich wrote:
On the DOM quirks point
Here's the thing. Ignoring for the moment the classes situation, it
seems to me that for DOM stuff specifically we have three options:
1) Have all DOM prototype stuff be enumerable. This leaves us in a
Conway's Law
On 1/12/14 11:57 PM, Andrea Giammarchi wrote:
Recap: it seems we agree classes properties and methods should not show
up in a for/in
I should note that web developers commonly expect DOM methods/properties
to show up in for/in (and in fact often write code depending on that,
sometimes
@dict ignore
non-enumerable properties, too?
Axel
On Jan 12, 2014, at 6:28 , Brendan Eich bren...@mozilla.com wrote:
Brendan Eich wrote:
I can only think of cases (including Claude Pache’s pro-enumerability
example) where I would want to copy *all* own properties.
Why do you want an array's
developers want ... I thought the fact basically every piece of code based
on `.hasOwnProperty()` check as first line of any `for/in` would be already
convincing nobody wants class enumerability and indeed I usually define
prototypes via defineProperties in a non enumerable way, but maybe I am the
only
On Sat, Jan 11, 2014 at 12:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I would like to see some Rick or David example about the expected to be
enumerable.
If that's about knowing if a class is native or not, looping with a for/in
its prototype or any instance does not seem
On Sat, Jan 11, 2014 at 12:57 PM, Andrea Giammarchi
andrea.giammar...@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
Giammarchi
andrea.giammar...@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
, 2014 at 8:21 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Sat, Jan 11, 2014 at 12:57 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Thanks Allen, makes sense ... but still no example where enumerability
of properties and method defined in a class prototype is useful
On Sun, Jan 12, 2014 at 11:45 PM, Andrea Giammarchi
andrea.giammar...@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?
Sometimes I find you incredibly
On Sun, Jan 12, 2014 at 11:57 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Recap: it seems we agree classes properties and methods should not show up
in a for/in ...
No we don't agree, because that's inconsistent with the behaviour that
exists today.
Rick
classes do not exist today and your example was about direct object, not
inherited from classes as they are meant in ES6.
I see from both here and Twitter you took this in a very wrong way while I
was asking rationale from those Allen's quotes you actually rephrased so I
just stop here.
All
I think it would really help the design of ECMAScript going forward if we
had a definitive and complete explanation of what enumerability is now and
what it should be in the future. I’m trying to make sense of it and to
explain it to others and continue to fail.
I can't provide
Axel Rauschmayer wrote:
Nice example. Data versus meta-data, in line with the `length` of an
array being non-enumerable.
Yes, and that's the primordial reason for enumerability. But it still
seems that class declaration users might want methods on the prototype
to be non-enumerable. Sauce
### I’m looking for a simple explanation of what enumerability will be,
going forward. If there isn’t one then I’d argue that no new feature should
be influenced by it.
That was one of the argument made in favor of concise methods defaulting as
not enumerable: enumerable really only
1 - 100 of 125 matches
Mail list logo
