On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
Since both Chrome and FIrefox have plans to support Promises, feel
free to suggest any changes to `es6-shim` which would improve
On 18 February 2014 10:43, Yehuda Katz wyc...@gmail.com wrote:
On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
Since both Chrome and FIrefox have plans to support Promises, feel
free
https://bugs.ecmascript.org/show_bug.cgi?id=2511
We now have our first setter in the spec. However, it is speced to return
the value itself. This is pretty inconsistent with WebIDL and the common
practice to not include a return value in setters in object literals.
Can we get the spec changed to
On Tue, Feb 18, 2014 at 10:29 AM, C. Scott Ananian csc...@cscott.netwrote:
Yes, and I'm pointing out that you can subclass built-ins in a compatible
manner even without the @@create hook,
How?
and hoping that we might see support for that (for Promises at least;
maybe Map/Set as well).
You can do so in the manner you were always able to in ES5, and you were able
to do in ES6 before the introduction of @@create. However, what this means is
that you now allow parastic inheritance again, which @@create was created to
disallow.
That is, you could have a MapPromiseWeakMap just by
On Feb 18, 2014, at 10:39 AM, Domenic Denicola wrote:
You can do so in the manner you were always able to in ES5, and you were able
to do in ES6 before the introduction of @@create. However, what this means is
that you now allow parastic inheritance again, which @@create was created to
Yes. For these same reasons, Date.call(obj) already doesn't work in ES5.
On Tue, Feb 18, 2014 at 10:54 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 18, 2014, at 10:39 AM, Domenic Denicola wrote:
You can do so in the manner you were always able to in ES5, and you were
able to
David Bruant wrote:
In practice, the returned value of setting is the value on the rhs of
the =.
var o = {set b(v){return 12;}} // this return statement is useless
console.log(o.a = 13); // 13
console.log(o.b = 14); // 14
It might be useful to return a different value on setting.
From: Allen Wirfs-Brock al...@wirfs-brock.com
No, even if you removed the checks in Map and Promise and WeakMap that
prevent them from trying to initialize an object that lacks the appropriate
internal slots it still wouldn't work because obj does not have the internal
slots necessary to
Domenic Denicola wrote:
Well, but you could just move the internal slot initialization into the
constructor itself (as Scott has done in his es6-shim promises). Unlike e.g.
`Array`, the objects returned by `Promise[@@create]` are not exotic objects;
they are simply normal objects with some
The same rationale would apply to Date, but making this change for Date
would be a breaking change. For consistency, let's not pick and choose
among builtins this way. We'll have @@create soon enough.
On Tue, Feb 18, 2014 at 11:09 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From:
Oh, for sure: I was not advocating a change in actual ES6. I was just
explaining on Scott's behalf how it was possible to have subclassable polyfills
before implementing @@create.
Implementations could, in theory, implement subclassable promises before
implementing @@create, via similar
On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
No, even if you removed the checks in Map and Promise and WeakMap that
prevent them from trying to initialize an object that lacks the appropriate
internal slots it still wouldn't work
On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
No, even if you removed the checks in Map and Promise and WeakMap that
prevent them from trying to
Le 17 févr. 2014 à 21:25, Brendan Eich bren...@mozilla.com a écrit :
C. Scott Ananian wrote:
But as you point out, I don't think there's any actual behavior
change, since everything washes out to `0` at the end. It's just a
matter of writing a clearer more consistent spec.
Yet in that
Le 17 févr. 2014 à 22:32, C. Scott Ananian ecmascr...@cscott.net a écrit :
Allen: I can volunteer to offload some of the work of auditing for
similar cases with default arguments. From a quick read-through, only
`Array#fill` seems to have the same issue. `Array#lastIndexOf` is
written in
On 2/18/14 1:07 PM, David Bruant wrote:
In practice, the returned value of setting is the value on the rhs of
the =.
That's the value of an assignment expression, yes.
var o = {set b(v){return 12;}} // this return statement is useless
Unless you explicitly getOwnPropertyDescriptor(o,
just my 0.02,
setter, considered inline, are more like:
```javascript
return doSomethingWith(name, value), value;
```
than
```javascript
var result = doSomethingWith(name, value);
return result === undefined ? value : result;
```
also because returning `undefined`, as setting `undefined`,
I like this refactoring. This doesn't change the spec's behavior;
this would be the first solution proposed in
https://bugs.ecmascript.org/show_bug.cgi?id=2546 which was to rewrite
the spec's non-normative text to make it clear that `end=this.length`
in the signature was describing the behavior
On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote:
ps. I'm talking about this pattern in particular:
```js
var SubPromise = function(exec) { Promise.call(this, exec); ... };
Object.setPrototypeOf(SubPromise, Promise);
SubPromise.prototype = Object.create(Promise.prototype);
On 2/18/14 2:51 PM, Allen Wirfs-Brock wrote:
I'm also a bit concerned, that there may be a meme starting that it will
be a looong time (years, if ever) before @@create is actually
implemented so JS developers really shouldn't count on being able to use
it if the foreseeable future. Such a
On Feb 18, 2014, at 1:12 PM, Boris Zbarsky wrote:
On 2/18/14 2:51 PM, Allen Wirfs-Brock wrote:
I'm also a bit concerned, that there may be a meme starting that it will
be a looong time (years, if ever) before @@create is actually
implemented so JS developers really shouldn't count on
On 2/18/14 4:34 PM, Allen Wirfs-Brock wrote:
In that case, i don't see why the DOM is a barrier to adding @@create to JS.
It's not, and I'm not quite sure where you thought I said it was
I was talking about actual uses of subclassing for DOM objects.
Maybe we should make DOM
On Feb 18, 2014, at 1:49 PM, Boris Zbarsky wrote:
On 2/18/14 4:34 PM, Allen Wirfs-Brock wrote:
You don't necessary need a new slot to to use as an initialized flag. I most
cases you can probably get away with using a not yet initialized token in
some existing slot.
While true, doing
Claude Pache wrote:
But I think that clarity can be improved by avoiding to obscure the intent by
computation details. For my personal polyfill, I have found useful to abstract
out the following steps, used (with slight variations) thrice in
`Array.prototype.copyWithin` and twice in
On Tue, Feb 18, 2014 at 3:34 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Of course adding an extra internal slot to all DOM objects is not
necessarily all that great either... Though maybe we have to do that no
matter what to prevent double-initialization.
You don't necessary need a
On Feb 18, 2014, at 4:59 PM, Jason Orendorff wrote:
On Tue, Feb 18, 2014 at 3:34 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Of course adding an extra internal slot to all DOM objects is not
necessarily all that great either... Though maybe we have to do that no
matter what to
On 2/18/14 4:57 PM, Allen Wirfs-Brock wrote:
I think that could be handled generically in the WebIDL spec. You can specify
it as if there was a per object initialized flag. But how that state is
actually represented can be left to actual implementations to deal with.
Yeah, agreed. I came
[resending to list, original was sent from wrong address and got bounced]
On Tue, Feb 18, 2014 at 11:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote:
```js
var SubPromise = function(exec) { Promise.call(this, exec); ... };
29 matches
Mail list logo
