Re: Wanted: standard Array function to append an array's
I may be late here, but what's wrong with
firstArray = firstArray.concat(secondArray); ?
If there are still problems I would say no magic method can solve them,
isn't it?
On Fri, Jul 29, 2011 at 1:59 AM, Jeff Walden jwalden...@mit.edu wrote:
On 07/27/2011 01:26 PM, John-David Dalton wrote:
@Jeff In reply to
https://mail.mozilla.org/**pipermail/es-discuss/2011-**July/016124.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2011-July/016124.html
,
which engines have problems with `firstArray.push.apply(**firstArray,
secondArray)` ?
Shouldn't a bug report be filed for the specific JS engine or the spec
be clarified on the subject (String.fromCharCode too) instead of
adding another method to Array.prototype?
Here's a testcase:
(function test() { var big = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xa, 0xb, 0xc,
0xd, 0xe, 0xf]; while (true) { try { var before = big.length;
big.push.apply(big, big); if (big.length !== before + before) throw before;
} catch (e) { return big.length + : + e; } } })()
If the apply call throws an exception, a string consisting of the array
length before the push failed, and the exception thrown, is returned. If
the push call doesn't push all the elements it should have pushed,a string
consisting of the array length after the push, and the array length before
the faulty push, is returned.
The testcase demonstrates failures with these engines:
SpiderMonkey's max argument-count is currently something like 480k, so
pushing an array of 512k elements onto another array will only push the
first 480k-ish. (This is being changed so that an exception is thrown,
shortly. It has caused at least two quite unexpected bugs. Probably
someone else has stumbled across the problem before, but I don't know for
sure.)
In v8 an exception is thrown sometime between secondArray having length
128k and 256k.
Nitro copied SpiderMonkey, although its max-arg-count isn't as high as
SpiderMonkey's, so it will only push the first N elements of a really big
array.
IE10 throws an exception for a push of the elements of an array somewhere
between 128k and 256k.
IE9 throws similarly, except between 256k and 512k.
Of the major engines, only Opera seems to have no problems here. I'm not
sure why this is. But ignoring Opera, everyone fails this. And the reason,
I believe, is not that it's a quality of implementation issue: it's that the
general way to implement this butts up against ingrained implementation
choices, and different engines will quite rationally behave in different
ways in response. push.apply is simply not a reliable substitute for a
built-in method to push the contents of an array into another array.
Jeff
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Wanted: standard Array function to append an array's elements to another array
to avoid apply limits is actually trivial:
var fromCharCode = (function ($fromCharCode, MAX_LENGTH) {
return function fromCharCode(code) {
typeof code == number (code = [code]);
for (var
result = [],
i = 0,
length = code.length;
i length; i += MAX_LENGTH
) {
result.push($fromCharCode.apply(null, code.slice(i, i +
MAX_LENGTH)));
}
return result.join();
};
}(String.fromCharCode, 2048));
// example
alert(fromCharCode(80)); // P
alert(fromCharCode([80,81,82,83,84])); // PQRST
about the pushAll I wonder if concat does not do already exactly what you
are looking for, as I wrote in the other thread.
Best Regards,
Andrea Giammarchi
On Mon, Jul 25, 2011 at 10:17 PM, Jeff Walden jwalden...@mit.edu wrote:
It's perhaps worth noting that this problem also occurs with
String.fromCharCode. I suspect the need for a version of
|String.fromCharCode.apply(**null, codesArray)| that always works, even
for super-big |codesArray|, is rather smaller than for the similar
Array.prototype.push concern.
Jeff
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Adding methods to {Array,String}.prototype
I like Underscore (http://documentcloud.github.com/underscore/). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions. I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON). [1] http://www.artima.com/articles/dci_vision.html -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Adding methods to {Array,String}.prototype
On Jul 29, 2011, at 9:53 AM, Axel Rauschmayer wrote: I like Underscore (http://documentcloud.github.com/underscore/). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions. I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON). I did not mean multimethods (generic functions is a confusing term, since it also means functions that work for parameters of any time; also generic suggests generics, i.e. type parameters). ES4 had a proposal for multimethods but I doubt it will make a come-back. Adding another dispatch mechanism to JS is a very hard sell. For dyadic operators, double dispatch is enough. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Adding methods to {Array,String}.prototype
On Jul 29, 2011, at 10:08 AM, Brendan Eich wrote: On Jul 29, 2011, at 9:53 AM, Axel Rauschmayer wrote: I like Underscore (http://documentcloud.github.com/underscore/). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions. I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON). I did not mean multimethods (generic functions is a confusing term, since it also means functions that work for parameters of any time s/time/type Coffee time! /be ; also generic suggests generics, i.e. type parameters). ES4 had a proposal for multimethods but I doubt it will make a come-back. Adding another dispatch mechanism to JS is a very hard sell. For dyadic operators, double dispatch is enough. /be ___ 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: Adding methods to {Array,String}.prototype
I like Underscore (http://documentcloud.github.com/underscore/). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions. I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON). I did not mean multimethods (generic functions is a confusing term, since it also means functions that work for parameters of any time; also generic suggests generics, i.e. type parameters). Understood, but generic functions (the way that Common Lisp and Dylan use that term) are a logical extension of JavaScript’s generic functions (the way ES-262 uses that term). Right now, JS generic functions have implicit contracts that one could make explicit (e.g. via some kind of duck typing). Type guards also seem loosely related. ES4 had a proposal for multimethods but I doubt it will make a come-back. Adding another dispatch mechanism to JS is a very hard sell. Right. That’s where my dreams come in. ;-) -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July TC39 meeting notes, day 1
I am wondering if you discussed the typeof null proposal? On Thu, Jul 28, 2011 at 9:46 PM, Andreas Rossberg rossb...@google.com wrote: On 28 July 2011 20:34, David Bruant david.bru...@labri.fr wrote: Le 28/07/2011 19:52, Andreas Rossberg a écrit : On 28 July 2011 10:35, David Bruant david.bru...@labri.fr wrote: Le 28/07/2011 06:21, Brendan Eich a écrit : == Handler access to proxies == Proxy handler traps need to receive the proxy as a parameter: first, or last? Last allows trap implementors to leave |proxy| off. It's also a compatible extension to the proposal and its prototype implementations. Putting |proxy| last may also steer implementors away from touching proxy, reducing the bugs where you infinitely diverge. First is more normal-order (proxy, name) and some find it more aesthetically pleasing. Another alternative: the proxy could be passed via a data property on the handler. I think we discussed already the idea of proxy being passed as a data property to the handler and came to the conclusion that it may not be a good idea, because it breaks the stratification. If two proxies use the same handler as in [2], then, there is an ambiguity on what the value of this property should be. The solution we discussed is to simply use prototypes. That is, share handler methods by putting them on a (single) prototype object, and have per-proxy instances that carry the individual proxy references (or other per-proxy data, for that matter). This is a pattern that I have seen used by Tom a lot and that I really like too, but you can't force a user to do that. So I assume, you would systematically add a base object and use the argument handler as its prototype? --- // h is a handler object var p1 = Proxy.create(h); var p2 = Proxy.create(h); --- When a user does this, what does he want? To use the exact same handler (same object identity)? Or to use the same logic but different internal properties? The solution you discussed seems to assume the latter, but who knows? And how do I implement the former if the proxy spec imposes that the object I pass internally becomes another object? I'm not sure I understand what you are asking. The solution I mentioned is purely user-side. There is no magic assumed in the proxy semantics. If you pass the same handler twice, it will be the same handler. If you need proxy-specific state, pass different handlers. If you still want some form of code sharing, use prototypal delegation. Now that I think about it, it's a bit weird that the proxy API allows to create several proxies with the same handler (same object identity). Maybe the API could be reworked in order to prevent it? Maybe Proxy.create should return the same proxy object if provided the same handler (p1 === p2, here)? I agree that there probably aren't too many useful examples for using the same handler. However, I also don't see a good reason for disallowing it, nor to require Proxy.create to memoise all handlers. /Andreas ___ 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: July TC39 meeting notes, day 1
On Jul 29, 2011, at 12:18 PM, Tom Schuster wrote: I am wondering if you discussed the typeof null proposal? No, that was accepted back in January, IIRC. We have to see how big a migration burden it is, still, but that can't be simulated. We need implementations and user testing. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Adding methods to {Array,String}.prototype
On 29 July 2011 19:08, Brendan Eich bren...@mozilla.com wrote: I did not mean multimethods (generic functions is a confusing term, since it also means functions that work for parameters of any time; also generic suggests generics, i.e. type parameters). Generic is a heavily overloaded term. I forgot who said it, but I remember a quote along the lines of by `generic' people always refer to the sort of polymorphism that your favourite language doesn't have. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: i18n meeting mid August @ Google
I could make any day that week except Tuesday. Wednesday would be best for me. On Fri, Jul 29, 2011 at 11:27 AM, Nebojša Ćirić c...@google.com wrote: Hi all, some topics were left unreviewed at the last face-to-face meeting. I would like to organize another F2F meeting/teleconference at Google campus mid August to finish up work on the first draft. Would week of *Aug 15th - 20th* work for you? We could meet on *Tuesday, from 10 - 17h*. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Wanted: standard Array function to append an array's
On 07/29/2011 05:01 AM, Andrea Giammarchi wrote: I may be late here, but what's wrong with firstArray = firstArray.concat(secondArray); ? If there are still problems I would say no magic method can solve them, isn't it? That creates a new array rather than mutate the array originally referred to by |firstArray| here, and I originally specified that only mutation was acceptable, because creating a new array requires extra space proportional to the length of |firstArray|. But I assume you're arguing that an engine could recognize that the copy could be transformed into a mutation. You'd have to prove that was the *only* reference to the original array in order to perform that optimization, or prove that it was observably correct to do that. Such analysis is tricky and costly time-wise. Relying on it would also be performance-fragile. If you were pushing incrementally onto an array (say, because you were appending arrays of bytes read from a network stream, saving them up to be processed all at once), the entire process is O(n) in bytes processed with push-through-mutation. But it's O(n**2) with push-by-copying. Thus you'd have to require the developer to understand when the optimization could be applied, in order to structure his code such that it would be applied. That level of understanding of compilers, and of the algorithms actually used to implement them (which won't be publicly available for some engines), seems way way beyond wh at can reasonably be expected of web developers. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Wanted: standard Array function to append an array's elements to another array
On 07/29/2011 05:22 AM, Andrea Giammarchi wrote: to avoid apply limits is actually trivial More or less, yes. But it requires the developer to anticipate the concern in advance that the elements being appended might consume all available stack space. I don't think most developers think at all about the size of the stack, or about its being limited, except when they write a recursive algorithm, intentionally or inadvertently, and neglect to correctly implement the base case. I certainly forgot about this concern when I wrote the buggy code which initially triggered this request, and I think it's reasonably apparent there's a problem when even a JS engine implementer makes this mistake. Past that, your MAX_LENGTH constant would have to be lower than the max length across all JS engines cared about. I find it concerning that something as simple as extending an array with the elements of another array would require an implementation-dependent workaround, when this operation is built-in functionality in other mainstream languages where mutation is common: C++: vectorT::insert http://www.cplusplus.com/reference/stl/vector/insert/ C#: ListT.AddRange http://msdn.microsoft.com/en-us/library/z883w3dc.aspx#Y570 Java: ListE.addAll http://download.oracle.com/javase/1.5.0/docs/api/java/util/List.html Perl: push http://perlmeme.org/howtos/perlfunc/push_function.html Python: list.extend http://docs.python.org/tutorial/datastructures.html Ruby: array.concat http://www.ruby-doc.org/core/classes/Array.html#M000224 Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July TC39 meeting notes, day 1
On Jul 29, 2011, at 5:42 PM, Kevin Reid wrote: On Fri, Jul 29, 2011 at 15:20, Mark S. Miller erig...@google.com wrote: -- Forwarded message -- From: Brendan Eich bren...@mozilla.com Date: Wed, Jul 27, 2011 at 9:21 PM == Handler access to proxies == [...] Conclusion: no rationale for adding a |proxy| parameter to all traps. == Proxy drop receiver == Sean Eagan pointed out in https://mail.mozilla.org/pipermail/es-discuss/2011-April/013916.html that the receiver parameter of Proxy handlers' get and set traps is useless, due to how these derived traps layer on fundamnetal traps. Conclusion: remove |receiver| from these traps. Hi; Mark Miller asked me to post this. I am a developer working on Google's Caja, writing ES5 code which uses proxies for our DOM virtualization. Thanks, you caught a blatant inconsistency in our reasoning. We used Sean's message (linked above) as a reason to remove receiver, that Sean wrote that message assuming both proxy and receiver would be parameters to get and set traps. Sean demonstrated that the two parameters would always have the same value, ergo only one was needed, and since at that time, proxy was considered important to keep (and add to all traps), receiver fell under the ax. But as noted higher above, at this week's meeting, we rejected adding proxy to all traps, including get and set. Therefore we must keep the receiver parameter of those two traps, for the reasons you give. Thanks again! /be Suppose a proxy handler wishes to implement the 'set' or 'get' trap in a way similar but not identical to the derived trap — similar in that it obtains a property descriptor (from the getOwnPropertyDescriptor trap or otherwise) and proceeds according to the contents of the descriptor. If the property being accessed is an accessor property, then the descriptor's 'get' or 'set' function should be invoked, *with 'this' being the proxy*. This behavior cannot be implemented purely within the handler object (i.e. without the explicit cooperation of the code calling Proxy.create) unless the proxy is passed to the handler. I consider it a useful principle that it should be possible for an object with a given method (the get/set trap of the handler, here) to implement the same behavior as will be performed by the caller (Proxy) if that method did not exist (the derived trap); therefore, I recommend that the 'get' and 'set' traps should have a parameter which is the proxy. I have no position on whether the proxy parameter should be first or last, or whether other traps should have one. -- Kevin Reid (Google intern) http://switchb.org/kpreid/ ___ 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: July TC39 meeting notes, day 1
On Jul 29, 2011, at 6:13 PM, Brendan Eich wrote: Thanks, you caught a blatant inconsistency in our reasoning. We used Sean's message (linked above) as a reason to remove receiver, that (but at the end of the above line instead of that, of course.) Sean wrote that message assuming both proxy and receiver would be parameters to get and set traps. Sean demonstrated that the two parameters would always have the same value, ergo only one was needed, and since at that time, proxy was considered important to keep (and add to all traps), receiver fell under the ax. But as noted higher above, at this week's meeting, we rejected adding proxy to all traps, including get and set. Therefore we must keep the receiver parameter of those two traps, for the reasons you give. Thanks again! The good news: the proxy traps as proposed are unchanged. Hats off to Tom and Mark for nailing that API and minimizing its parameterization! Proxies have two prototype implementations now: Firefox since 4, and now V8 (http://code.google.com/p/v8/source/detail?r=8733) -- not sure when that shows up under a flag in Chrome canaries, someone from Google will know. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July TC39 meeting notes, day 1
On Fri, Jul 29, 2011 at 10:31 PM, Kevin Reid kpr...@google.com wrote: On Fri, Jul 29, 2011 at 19:57, Brendan Eich bren...@mozilla.com wrote: The good news: the proxy traps as proposed are unchanged. Hats off to Tom and Mark for nailing that API and minimizing its parameterization! Proxies have two prototype implementations now: Firefox since 4, and now V8 (http://code.google.com/p/v8/source/detail?r=8733) -- not sure when that shows up under a flag in Chrome canaries, someone from Google will know. Just to clarify: “as proposed” = the current version of http://wiki.ecmascript.org/doku.php?id=harmony:proxies? That is, will the proxy parameter remain first, rather than last? We can certainly continue discussing this. But let's postpone trying to resolve any of this until Tom gets back from vacation. I still suspect there was some crucial point Tom had explained to me that I forgot. ___ 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
