On Tue, Jun 9, 2015 at 7:58 AM, C. Scott Ananian <ecmascr...@cscott.net> wrote:
> Mark: I outlined two of these use cases in > https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50 > > One is `WeakPromise` which is a promise holding a weak reference to its > resolved value. This is the closest analogy with the canonical Smalltalk > motivating example for species. > > Another is `TimeoutPromise` which is a promise that rejects in a fixed > time if not resolved before then. > > Both of these would set `WeakPromise[Symbol.species] = > TimeoutPromise[Symbol.species] = Promise;` so that the weak > reference/timeout is not "contagious" across `then()`. > Ok, thanks for the example. I understand your rationale. This is what I asked for but not what I was really looking for. Can we come up with an example where class and species usefully differ where neither is Promise? IOW, where the species a proper subclass of Promise and a proper superclass of the class in question. Btw, Allen's conclusion sounds right to me. But I'd like to see such an example, or see us fail to find one, before considering the what-it-should-be-in-the-absence-of-timing issue settled. Thanks. Given the timing, unless the case is very strong, which you clearly doubt as well, I'm sure we won't actually revisit this for ES6, and thus never. > `WeakPromise.all([...])` reads like it should return a `WeakPromise` (ie, > ignore species). This is consistent with the "static methods ignore > species" rule. > > *However*, `WeakPromise.resolve([....]).all()` makes it clearer that weak > reference held by `WeakPromise` is actually just to the initial array, and > that the result of `WeakPromise.prototype.all` should in fact be a > `Promise` (ie, honor species). > > Similarly for `TimeoutPromise`: `TimeoutPromise.resolve([...]).all()` > implies a timeout to resolve the initial array-of-promises, but the result > of the `all()` is a normal Promise and won't timeout. But on the other > hand, you wouldn't be wrong if you thought that `TimeoutPromise.all([...])` > should timeout the result of the all. > > So, to me it seems like if you think that `Promise.all(x)` is shorthand > for a future `this.resolve(x).all()`, then honoring the species is not a > terrible thing. In ES7-ish, when you allow `Promise.all` and > `Promise.race` to accept Promises as their arguments (in addition to > iterables), then you could clarify the spec to indicate that the species is > ignored when resolving the Promise argument, then honored when processing > the `all` or `race`. > > But if you want a crisp semantics and weren't afraid of more last-minute > changes to the Promise spec, then you'd define `Promise.all` and > `Promise.race` to ignore species, and handle the species issue in ES7 when > you define `Promise.prototype.all` and `Promise.prototype.race`. > > IMO, at least. > --scott > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
