[resending to list, original was sent from wrong address and got bounced]
On Tue, Feb 18, 2014 at 11:12 AM, Allen Wirfs-Brock
wrote:
> On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote:
>> ```js
>> var SubPromise = function(exec) { Promise.call(this, exec); ... };
>> Object.setPrototypeOf(SubP
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 t
On Feb 18, 2014, at 4:59 PM, Jason Orendorff wrote:
> On Tue, Feb 18, 2014 at 3:34 PM, Allen Wirfs-Brock
> 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
On Tue, Feb 18, 2014 at 3:34 PM, Allen Wirfs-Brock
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 new slot to t
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 `Array.pro
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.
>
> Whil
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 constructors
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 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 m
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);
> S
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 in
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`, wou
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",
Le 17 févr. 2014 à 22:32, C. Scott Ananian 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 the ES5 style, w
Le 17 févr. 2014 à 21:25, Brendan Eich 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 light you sti
On Feb 18, 2014, at 11:29 AM, Mark S. Miller wrote:
>
>
>
> On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock
> wrote:
> ...
>
> It probably isn't appropriate for implementors to unilaterally decide whether
> or not this is a low priority feature.
>
> Hi Allen, I agree with the rest, bu
On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock
wrote:
>
> On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:
>
> > From: Allen Wirfs-Brock
> >
> >> 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 appr
On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:
> From: Allen Wirfs-Brock
>
>> 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
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 semant
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
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 int
From: Allen Wirfs-Brock
> 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 support the built-i
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.
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
wrote:
>
> 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
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
>
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 Tue, Feb 18, 2014 at 10:29 AM, C. Scott Ananian wrote:
> 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).
> --scott
>
On Feb 18, 2014, at 9:55 AM, Erik Arvidsson wrote:
> 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 valu
Le 18/02/2014 18:55, Erik Arvidsson a écrit :
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
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 18 February 2014 10:43, Yehuda Katz wrote:
> On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren wrote:
>>
>> On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
>> wrote:
>> > Since both Chrome and FIrefox have plans to support Promises, feel
>> > free to suggest any changes to `es6-shim` whic
On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren wrote:
> On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
> wrote:
> > Since both Chrome and FIrefox have plans to support Promises, feel
> > free to suggest any changes to `es6-shim` which would improve
> > compatibility. It looks like that
32 matches
Mail list logo