Re: Array.prototype.last()
Previous discussion on this topic: http://esdiscuss.org/topic/array-prototype-last We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have [`_.first`](http://lodash.com/docs#first) and [`_.last`](http://lodash.com/docs#last), which both take an optional `callback` parameter, in which case all the first/last `n` elements for which `callback` returns a truthy value are returned. This seems like a sensible thing to add to the proposal. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.last()
On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens mathi...@opera.com wrote: Previous discussion on this topic: http://esdiscuss.org/topic/array-prototype-last We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have [`_.first`]( http://lodash.com/docs#first) and [`_.last`](http://lodash.com/docs#last), which both take an optional `callback` parameter, in which case all the first/last `n` elements for which `callback` returns a truthy value are returned. This seems like a sensible thing to add to the proposal. While I think having .last would be nice, I don't think it's worth the considerable backwards-compatibility issues. We had to temporarily back out Array#values from SpiderMonkey until we implement @@unscopable semantics[1], because we ran into serious real-world breakage. I'm pretty sure that last would break a lot more code, as it's even easier to think up scenarios where that'd be used as a property name on an array used in application logic. At the very least, I think having Array#last be a getter is entirely untenable: a method would at least just be overwritten in most cases, whereas a read-only accessor would just (silently, in non-strict code) fail. A read-write accessor would probably be even worse: it'd silently (in all code) do something entirely different than it did before. I do, however, like Axel's proposal[2] of adding .get() and .set() to Array.prototype, and think that that'd be way less of a compatibility issue. [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32185 [2]: http://esdiscuss.org/topic/array-prototype-last#content-5 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.last()
On Wed, May 14, 2014 at 5:37 AM, Till Schneidereit t...@tillschneidereit.net wrote: On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens mathi...@opera.comwrote: Previous discussion on this topic: http://esdiscuss.org/topic/array-prototype-last We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have [`_.first`]( http://lodash.com/docs#first) and [`_.last`](http://lodash.com/docs#last), which both take an optional `callback` parameter, in which case all the first/last `n` elements for which `callback` returns a truthy value are returned. This seems like a sensible thing to add to the proposal. While I think having .last would be nice, I don't think it's worth the considerable backwards-compatibility issues. We had to temporarily back out Array#values from SpiderMonkey until we implement @@unscopable semantics[1], because we ran into serious real-world breakage. I'm pretty sure that last would break a lot more code, as it's even easier to think up scenarios where that'd be used as a property name on an array used in application logic. At the very least, I think having Array#last be a getter is entirely untenable: a method would at least just be overwritten in most cases, whereas a read-only accessor would just (silently, in non-strict code) fail. A read-write accessor would probably be even worse: it'd silently (in all code) do something entirely different than it did before. I do, however, like Axel's proposal[2] of adding .get() and .set() to Array.prototype, and think that that'd be way less of a compatibility issue. [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32185 [2]: http://esdiscuss.org/topic/array-prototype-last#content-5 I forgot about this, thanks for posting. I like get() much better as it can be a first or a last (or any in between) with less surface impact. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.last()
I like we keep adding `get` and `set` here and there but I hope we are not forgetting to fix descriptors inheritance problem where any `get` or `set` can compromise `Object.defineProperty` operations (just a gently reminder that `get` and `set` if inherited can cause many troubles in ES5 like operations) Best Regards On Wed, May 14, 2014 at 8:00 AM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, May 14, 2014 at 5:37 AM, Till Schneidereit t...@tillschneidereit.net wrote: On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens mathi...@opera.comwrote: Previous discussion on this topic: http://esdiscuss.org/topic/array-prototype-last We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have [`_.first`](http://lodash.com/docs#first) and [`_.last`]( http://lodash.com/docs#last), which both take an optional `callback` parameter, in which case all the first/last `n` elements for which `callback` returns a truthy value are returned. This seems like a sensible thing to add to the proposal. While I think having .last would be nice, I don't think it's worth the considerable backwards-compatibility issues. We had to temporarily back out Array#values from SpiderMonkey until we implement @@unscopable semantics[1], because we ran into serious real-world breakage. I'm pretty sure that last would break a lot more code, as it's even easier to think up scenarios where that'd be used as a property name on an array used in application logic. At the very least, I think having Array#last be a getter is entirely untenable: a method would at least just be overwritten in most cases, whereas a read-only accessor would just (silently, in non-strict code) fail. A read-write accessor would probably be even worse: it'd silently (in all code) do something entirely different than it did before. I do, however, like Axel's proposal[2] of adding .get() and .set() to Array.prototype, and think that that'd be way less of a compatibility issue. [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32185 [2]: http://esdiscuss.org/topic/array-prototype-last#content-5 I forgot about this, thanks for posting. I like get() much better as it can be a first or a last (or any in between) with less surface impact. Rick ___ 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
Bytecode
What is the best “bytecode isn’t everything” article that exists? The “the web needs bytecode” meme comes up incredibly often, I’d like to have something good to point to, as an answer. This one looks good: http://mozakai.blogspot.de/2013/05/the-elusive-universal-web-bytecode.html Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de Check out my new book: SpeakingJS.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.last()
Same any valid reason inheritance should be considered for descriptors ... I didn't want to go off topic too much, just remind that these methods name have a very important meaning in some case. Best Regards On Wed, May 14, 2014 at 10:31 AM, Andri Möll an...@dot.ee wrote: How are they related? Wouldn't that affect Object.defineProperty only if someone passes it an object inheriting from array, for which I can't think any valid reason for. Andri On May 14, 2014, at 8:10 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I like we keep adding `get` and `set` here and there but I hope we are not forgetting to fix descriptors inheritance problem where any `get` or `set` can compromise `Object.defineProperty` operations (just a gently reminder that `get` and `set` if inherited can cause many troubles in ES5 like operations) Best Regards On Wed, May 14, 2014 at 8:00 AM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, May 14, 2014 at 5:37 AM, Till Schneidereit t...@tillschneidereit.net wrote: On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens mathi...@opera.comwrote: Previous discussion on this topic: http://esdiscuss.org/topic/array-prototype-last We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have [`_.first`](http://lodash.com/docs#first) and [`_.last`]( http://lodash.com/docs#last), which both take an optional `callback` parameter, in which case all the first/last `n` elements for which `callback` returns a truthy value are returned. This seems like a sensible thing to add to the proposal. While I think having .last would be nice, I don't think it's worth the considerable backwards-compatibility issues. We had to temporarily back out Array#values from SpiderMonkey until we implement @@unscopable semantics[1], because we ran into serious real-world breakage. I'm pretty sure that last would break a lot more code, as it's even easier to think up scenarios where that'd be used as a property name on an array used in application logic. At the very least, I think having Array#last be a getter is entirely untenable: a method would at least just be overwritten in most cases, whereas a read-only accessor would just (silently, in non-strict code) fail. A read-write accessor would probably be even worse: it'd silently (in all code) do something entirely different than it did before. I do, however, like Axel's proposal[2] of adding .get() and .set() to Array.prototype, and think that that'd be way less of a compatibility issue. [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32185 [2]: http://esdiscuss.org/topic/array-prototype-last#content-5 I forgot about this, thanks for posting. I like get() much better as it can be a first or a last (or any in between) with less surface impact. Rick ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.last()
How are they related? Wouldn't that affect Object.defineProperty only if someone passes it an object inheriting from array, for which I can't think any valid reason for. Andri On May 14, 2014, at 8:10 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I like we keep adding `get` and `set` here and there but I hope we are not forgetting to fix descriptors inheritance problem where any `get` or `set` can compromise `Object.defineProperty` operations (just a gently reminder that `get` and `set` if inherited can cause many troubles in ES5 like operations) Best Regards On Wed, May 14, 2014 at 8:00 AM, Rick Waldron waldron.r...@gmail.com wrote: On Wed, May 14, 2014 at 5:37 AM, Till Schneidereit t...@tillschneidereit.net wrote: On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens mathi...@opera.com wrote: Previous discussion on this topic: http://esdiscuss.org/topic/array-prototype-last We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have [`_.first`](http://lodash.com/docs#first) and [`_.last`](http://lodash.com/docs#last), which both take an optional `callback` parameter, in which case all the first/last `n` elements for which `callback` returns a truthy value are returned. This seems like a sensible thing to add to the proposal. While I think having .last would be nice, I don't think it's worth the considerable backwards-compatibility issues. We had to temporarily back out Array#values from SpiderMonkey until we implement @@unscopable semantics[1], because we ran into serious real-world breakage. I'm pretty sure that last would break a lot more code, as it's even easier to think up scenarios where that'd be used as a property name on an array used in application logic. At the very least, I think having Array#last be a getter is entirely untenable: a method would at least just be overwritten in most cases, whereas a read-only accessor would just (silently, in non-strict code) fail. A read-write accessor would probably be even worse: it'd silently (in all code) do something entirely different than it did before. I do, however, like Axel's proposal[2] of adding .get() and .set() to Array.prototype, and think that that'd be way less of a compatibility issue. [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32185 [2]: http://esdiscuss.org/topic/array-prototype-last#content-5 I forgot about this, thanks for posting. I like get() much better as it can be a first or a last (or any in between) with less surface impact. Rick ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bytecode
Axel Rauschmayer wrote: What is the best “bytecode isn’t everything” article that exists? The “the web needs bytecode” meme comes up incredibly often, I’d like to have something good to point to, as an answer. This one looks good: http://mozakai.blogspot.de/2013/05/the-elusive-universal-web-bytecode.html That's a good one. It reflects lots of discussions Alon and others, including yours truly, have had over the years. The important point is not just bytecode isn't everything -- also important are trade-offs in have two syntaxes, something that came up here on es-discuss long ago. Here's a post from Maciej of Apple: https://mail.mozilla.org/pipermail/es-discuss/2009-December/010238.html The topic then was AST encoding, not something people think of as bytecode. Michael Franz at UCI and Ben Livshits at MSR had worked on arithmetic coding of ASTs (avoids need for verification). The topic is deep and memes die hard. I think Alon's post is the right thought-piece; anyone have others? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bytecode
It'd be great if there was material on the limits of the JVM and the CLR. AFAICT these are the only virtual machines that are trying to be universal (run both static and dynamic languages well). [[[Sent from a mobile device. Please forgive brevity and typos.]]] Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com On 15.05.2014, at 03:02, Brendan Eich bren...@mozilla.org wrote: Axel Rauschmayer wrote: What is the best “bytecode isn’t everything” article that exists? The “the web needs bytecode” meme comes up incredibly often, I’d like to have something good to point to, as an answer. This one looks good: http://mozakai.blogspot.de/2013/05/the-elusive-universal-web-bytecode.html That's a good one. It reflects lots of discussions Alon and others, including yours truly, have had over the years. The important point is not just bytecode isn't everything -- also important are trade-offs in have two syntaxes, something that came up here on es-discuss long ago. Here's a post from Maciej of Apple: https://mail.mozilla.org/pipermail/es-discuss/2009-December/010238.html The topic then was AST encoding, not something people think of as bytecode. Michael Franz at UCI and Ben Livshits at MSR had worked on arithmetic coding of ASTs (avoids need for verification). The topic is deep and memes die hard. I think Alon's post is the right thought-piece; anyone have others? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bytecode
On Wed, May 14, 2014 at 9:12 PM, Axel Rauschmayer a...@rauschma.de wrote: It'd be great if there was material on the limits of the JVM and the CLR. AFAICT these are the only virtual machines that are trying to be universal (run both static and dynamic languages well). Well, from experience, the JVM is/was handicapped by some incidental decisions in its original standard library[*] that have a large adverse impact on startup time. This has restricted the 'usefulness' of the JVM from its inception. There are projects to re-engineer the standard library around this, but they have been slow (and are not yet complete)[**]. Similarly, the support for dynamic languages is fairly recent (JDK 7, JavaScript implementation using these features in JDK 8), so it's a bit early to know how that will play out in terms of adoption and practical use. So I'm not sure how much you're going to learn from the JVM, other than no matter how good/bad your bytecode is, other factors may dominate. That is: I would doubt most conclusions about bytecodes drawn from the example of the JVM, since I don't believe the bytecode design was a first order effect on its trajectory to date. That said, my favorite bytecode anecdote from the JVM is that the amount of space wasted in class files by renaming the language from 'oak' to 'java' was far greater than the amount of space saved by adding a 'jsr' instruction to bytecode (which was intended to allow finally clauses without code duplicate). However, the jsr instruction was a disaster: it was responsible for the first security exploits in the JVM's early days, greatly complicated code verification (inspiring a bunch of new academic research! which is never something you want in a production language design), and slowed down execution by disallowing efficient bytecode verification techniques. It was ultimately deprecated in Java 6. So: if you want small bytecode files, sometimes it's better just to rename your language! --scott (a recovering Java compiler engineer) [*] My fuzzy recollection of one such: The `java.lang.System` class included the stdout/stdin/stderr fields `System.out`, `System.in`, `System.err` which as bytestreams needed to deal with the charset of the I/O streams (since Strings were natively UTF-16) and so ended up pulling in a huge list of supported charsets and charset conversion classes, totaling many hundreds of kilobytes of bytecode, none of which could be statically prebuilt because selecting the proper charset depended on the user's environment variable settings at runtime. The amount of ancillary code pulled in by the charset conversion machinery included `System.properties` (to read that environment variable), which was a `Map` subclass, so pulled in most of the Collections API, etc, etc. [**] See http://openjdk.java.net/projects/jigsaw/ and the blog entries linked there. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
