On Wed, Jun 10, 2015 at 7:37 AM, Allen Wirfs-Brock
wrote:
>
> On Jun 9, 2015, at 9:53 AM, C. Scott Ananian wrote:
>
> On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller
> wrote:
>
>> Do you ever test that the object returned by `Promise#timeout(n)` is
>> something other than a plain promise?
>>
>
>
On Wed, Jun 10, 2015 at 10:37 AM, Allen Wirfs-Brock
wrote:
> However, I think that Promise.reject should parallel Promise.resolve and
> hence it should not use species.
>
I agree.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mai
On Jun 9, 2015, at 9:53 AM, C. Scott Ananian wrote:
> On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller wrote:
> Do you ever test that the object returned by `Promise#timeout(n)` is
> something other than a plain promise?
>
> Responded on the other thread.
>
> Let's keep this one focused on: do
On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller wrote:
> Do you ever test that the object returned by `Promise#timeout(n)` is
> something other than a plain promise?
>
Responded on the other thread.
Let's keep this one focused on: do we need to tweak the definitions of
`Promise.all` and `Promis
On Tue, Jun 9, 2015 at 9:29 AM, C. Scott Ananian
wrote:
> Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
> `TimeoutPromise` subclass. But this is really a language-design question.
> You might as well ask why we have `WeakMap()` as a constructor instead of
> using `Map#
Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
`TimeoutPromise` subclass. But this is really a language-design question.
You might as well ask why we have `WeakMap()` as a constructor instead of
using `Map#weak()` or `weakmapify(map)`. The fundamental reason is "so you
c
I know I'm being picky here, but if timeout-ness is not intended to
propagate, which seems sensible, then why would I ever want to invent a
TimeoutPromise subclass rather than using a combinator like delay or race
on a plain Promise?
___
es-discuss mailin
On Tue, Jun 9, 2015 at 11:11 AM, Mark S. Miller wrote:
> 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 s
On Tue, Jun 9, 2015 at 7:58 AM, C. Scott Ananian
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
On Jun 9, 2015, at 7:30 AM, C. Scott Ananian wrote:
> `Promise.resolve` doesn't use the species pattern any more:
> https://esdiscuss.org/topic/fixing-promise-resolve
> The rationale was that `resolve` is more like a constructor than a mutator.
>
> I don't have a strong opinion about `Promise.a
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
I'd appreciate further opinions here. My bias is against trying to make
> late changes to the ES6 spec, so perhaps I'm rationalizing away the
> potential problems with `Promise.all` and `Promise.race`.
> --scott
>
>
> On Tue, Jun 9, 2015 at 6:46 AM, Axel Rauschmayer
t trying to make
late changes to the ES6 spec, so perhaps I'm rationalizing away the
potential problems with `Promise.all` and `Promise.race`.
--scott
On Tue, Jun 9, 2015 at 6:46 AM, Axel Rauschmayer wrote:
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall
&g
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall
<https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall>
I’m wondering: Is it OK that PerformPromiseAll invokes `resolve()` via
`C.resolve()` (versus `this.resolve()`) with `C` determined v
14 matches
Mail list logo
