Re: Proposal: Abstract References
Oh. I see now. The function calling part I understand already.
For the private state ideas, I can see the GC speed nightmare, but for just
function binding, it is extraordinarily similar to LiveScript's `|`
operator (which has always been useful) in usage, which I'm +1,000 for
that.
On Oct 22, 2014 7:06 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 22, 2014 at 1:12 PM, Isiah Meadows impinb...@gmail.com
wrote:
I know that this could clearly work for implementing private arrays,
etc. as
well, but what about private integer or booleans?
```js
let _x = 0;
let _y = false;
class Foo {
constructor(x, y) {
this::_x = x;
this::_y = y;
}
// ...
}
You misunderstand the proposal a bit. In `x::y`, the y is an object
that is asked to respond in a special way. When `y` is a WeakMap, it
responds to `x::y = z;` by calling `y.set(x, z)` on itself.
You can store whatever you want in there; the `z` value can be
anything, including numbers or booleans. But the `y` object needs to
be something that knows how to respond to the bind operator.
(Similarly, if `y` is a function, by default it responds to `x::y(z)`
by calling itself with its `this` set to `x`. This makes it act
similarly to `x.y(z)`, but without having to actually define `y` as a
property on `x`.)
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Abstract References
For the private state ideas, I can see the GC speed nightmare, See Mark's posts regarding GC. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.values is not web compat (even with unscopables)
On 10/17/14, 16:13, Jeff Walden wrote: On 10/17/2014 01:53 PM, Erik Arvidsson wrote: [1] Microsoft Outlook Calendar web app (part of Exchange Outlook Web Access) Microsoft could ship a fix in a point release, right? They surely already provide security patches that admins must install anyway, if they want to keep their users (and their data) safe. If the fix is small, is there any reason why it couldn't be part of such a patch? I filed https://github.com/webcompat/web-bugs/issues/388 to track Microsoft adding the forOwnProperty fix. Microsoft's @TheWebJustWorks team has been really helpful in the past for these kinds of issues. -- Mike Taylor Web Compat, Mozilla ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Very large array indices and unshift/splice
Consider the following snippet, along with the spec for
Array.prototype.unshift (
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.unshift
):
var arr = [];
arr[0xfffe] = 10;
try {
arr.unshift(1);
} catch(e) {
// e is a RangeError, since the unshift operation will try to set the
length to 0x
}
what should the state of arr be after this botched operation? The way the
spec is written, all the element manipulation happens before the RangeError
occurs, so arr[0x] should be 10 and arr[0xfffe] should have
been deleted.
But it's not clear this is worthwhile. I tested this in V8, SpiderMonkey,
and JSC.
V8 properly throws a range error, but fails to move the element up one
index.
SpiderMonkey hangs (presumably because it has no special logic to deal with
very large, sparse arrays).
JSC throws an Out of memory Error and also fails to move the element up
one index.
A similar thing happens if one attempts to splice items into the array.
Is there any reason not to specify some precondition checking in these
algorithms and spec them to throw the RangeError without interacting with
the elements of the array if it's known a priori that the resulting length
will be 2^32-1?
In V8 and JSC this nearly matches existing behavior. In Firefox it would
cause a change in behavior, but any code depending on the existing behavior
would be hanging for a long time already.
- Adam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Very large array indices and unshift/splice
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Adam Klein Is there any reason not to specify some precondition checking in these algorithms and spec them to throw the RangeError without interacting with the elements of the array if it's known a priori that the resulting length will be 2^32-1? ES6 adjusted the length limit upward to 2^53 - 1, IIRC... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Very large array indices and unshift/splice
Domenic Denicola wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Adam Klein Is there any reason not to specify some precondition checking in these algorithms and spec them to throw the RangeError without interacting with the elements of the array if it's known a priori that the resulting length will be 2^32-1? ES6 adjusted the length limit upward to 2^53 - 1, IIRC... And yet Adam cited the draft ES6 HTML-formatted spec. Seems like two problems: * Error-checking after mutating -- in this case in ArraySetLength from Array [[DefineOwnProperty]] from Put 7(b)(v)(3) in 22.1.3.28 -- buried! * The lack of 53-bit indexes, but isn't this waiting for a VM to try and see what breaks? Cc'ing Allen. Buggy engines too, but perhaps their maintainers will want to wait a bit before fixing ;-). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Very large array indices and unshift/splice
From: Brendan Eich [mailto:bren...@mozilla.org] And yet Adam cited the draft ES6 HTML-formatted spec. * The lack of 53-bit indexes, but isn't this waiting for a VM to try and see what breaks? Cc'ing Allen. Interesting; there's an inconsistency between ToLength() which uses ToInteger() + min(x, 2^53 - 1) vs. ArraySetLength() which uses ToUint32(). Maybe it is intentional so that everywhere else that uses ToLength() gets to use large indices, but you can't actually put that many elements in a (non-typed) array? In any case, I see the issue now... it does seem like a convoluted path to get to that error. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Very large array indices and unshift/splice
I can only answer briefly right now: This is intentional. Array instances are still limited to 2^32-2 elements. Compat issues to change. But, the generic array methods aren't restricted to Array instances and support larger lengths in those cases. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Very large array indices and unshift/splice
Allen Wirfs-Brock wrote: I can only answer briefly right now: This is intentional. Array instances are still limited to 2^32-2 elements. Compat issues to change. But, the generic array methods aren't restricted to Array instances and support larger lengths in those cases. Hi Allen, appreciate brief reply. Still leaves mutation before error problem -- want a spec bug? Impl bugs to follow. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Abstract References
That was an indirect reference. Sorry for the obscurity. For the private state ideas, I can see the GC speed nightmare, See Mark's posts regarding GC. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Very large array indices and unshift/splice
Ok, I've only had time to do a cursory check, but based upon quick inspection the ES6 spec. for unshift appears to to produce observably identical results when operating upon an an Array instance of max length. That's what supposed to happen, ES5 didn't specify any precondition checks, so to do so now is, in theory, a breaking change. In practice it might not matter, but nobody knows for sure. if there are what appears to be unintentional differences between the behavior or the ES5 and ES6 spec, then bugs should be file. It's also reasonable to file bugs suggesting that a change to the ES5 behavior should be make but the submitter should try to justify why it is ok to make such a breaking change. Finally, at this stage of the release game, bugs that contain detailed patches to the currently specified algorithms are more likely to get attention then those that lack that level of detail. Allen On Oct 23, 2014, at 5:44 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: I can only answer briefly right now: This is intentional. Array instances are still limited to 2^32-2 elements. Compat issues to change. But, the generic array methods aren't restricted to Array instances and support larger lengths in those cases. Hi Allen, appreciate brief reply. Still leaves mutation before error problem -- want a spec bug? Impl bugs to follow. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Very large array indices and unshift/splice
Allen Wirfs-Brock wrote: ES5 didn't specify any precondition checks, so to do so now is, in theory, a breaking change. In practice it might not matter, but nobody knows for sure. Unlikely, given what Adam reported: V8 properly throws a range error, but fails to move the element up one index. SpiderMonkey hangs (presumably because it has no special logic to deal with very large, sparse arrays). JSC throws an Out of memory Error and also fails to move the element up one index. Anyone care to test IE? In practice, near the 2^31 - 1 maximum value for an arraylike's length, there's no reliable interop today. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
