Re: ES6 iteration over object values
Le 16/03/2014 00:45, Rick Waldron a écrit :
On Sat, Mar 15, 2014 at 7:38 PM, Jason Orendorff
jason.orendo...@gmail.com mailto:jason.orendo...@gmail.com wrote:
On Sat, Mar 15, 2014 at 5:19 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Even if error prone, I'd be interested to hear about arguments
in the sense
that the risk outweighs the benefits. Iterable-by-default
objects is a nice
battery included feature.
I'm pretty sure es-discuss has been over this, but it doesn't hurt
to restate:
1. This would mean that evolving any object in any API from *not*
having an @@iterator method to providing its own @@iterator method
would be a backward compatibility risk. Existing code might be using
the default @@iterator to enumerate the object's properties.
2. The default Object.prototype.@@iterator would not appear on
Object.create(null), so the one kind of object people would most want
to have this behavior (Objects specifically created for use as
dictionaries) would be the only kind of object that wouldn't have it.
A separate function would be better---you could apply it to anything
with properties.
Either reason alone would be enough, but to me #1 is a killer.
Platform evolution hazards are bad news. You get stuff like
Array.prototype.values being backed out of browsers, and then you get
stuff like @@unscopables.
I'd like to see an Object.entries method, and Object.values for
completeness. Same visibility rules as Object.keys.
for (let [k, v] of Object.entries(myObj)) {
// do something with k and v
}
Very enthusiastically agree---these would be excellent additions that
balance nicely with Dict (null __proto_ b/w keys, values, entries),
along with all of the builts-ins that received keys, values and
entries on their prototypes in ES6.
Alright, convinced too.
Thanks :-)
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Source maps (was: Multiline Strings)
On 3/14/14 at 3:02 PM, fitz...@gmail.com (Nick Fitzgerald) wrote: I feel very strongly that users debugging their sources that were compiled to js should be able to set watch expressions and conditional breakpoints in their source language. My experience with debuggers says the while the vast majority of the time you want to be able to debug it in the language you wrote, sometimes you want to debug it in the language it broke in. Being able to look at the lower level language can clear up misconceptions about what a higher level construct means. It can also reveal compiler bugs. It should also be recognized that all compiled programs break in machine language. :-) Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Source maps (was: Multiline Strings)
The accuracy of this aside, history shows that most of my users are not satisfied by 'just debug the JS, it's fairly readable'. Maybe emscripten, gwt, etc. users are more fluent in JS and don't mind debugging it, but based on what I've seen, maybe not... I do think it's important that source maps don't obscure what's happening at the JS level, though - presumably all the modern debuggers let you toggle them back off once they're loaded, so that's satisfied? -kg On Sun, Mar 16, 2014 at 11:03 AM, Bill Frantz fra...@pwpconsult.com wrote: On 3/14/14 at 3:02 PM, fitz...@gmail.com (Nick Fitzgerald) wrote: I feel very strongly that users debugging their sources that were compiled to js should be able to set watch expressions and conditional breakpoints in their source language. My experience with debuggers says the while the vast majority of the time you want to be able to debug it in the language you wrote, sometimes you want to debug it in the language it broke in. Being able to look at the lower level language can clear up misconceptions about what a higher level construct means. It can also reveal compiler bugs. It should also be recognized that all compiled programs break in machine language. :-) Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Source maps (was: Multiline Strings)
K. Gadd wrote: The accuracy of this aside, history shows that most of my users are not satisfied by 'just debug the JS, it's fairly readable'. Maybe emscripten, gwt, etc. users are more fluent in JS and don't mind debugging it, but based on what I've seen, maybe not... I do think it's important that source maps don't obscure what's happening at the JS level, though - presumably all the modern debuggers let you toggle them back off once they're loaded, so that's satisfied? I think so. Bill's point is well taken, but a tangent. The problem people face is debugging in their primary source language, mainly. Any problems with JS-level debugging are lesser and more readily solved. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
