Why thenables?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Why thenables?

David Bruant-5
Hi,

The question of thenables came back on Mozilla's Bugzilla [1] (see
comment 29 & 30) with a decent share of skepticism that I share too.

I'm sorry I didn't go through all the promises discussions, but what's
the rationale of supporting thenables? I fear this feature won't be
necessary 2 or 3 years after native promises ship. For sure, it's of no
use to those who only use native promises.

I read from the meeting notes that it was pretty much the only point of
debate and a long one.

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=879245
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Rick Waldron



On Thu, Oct 10, 2013 at 6:26 PM, David Bruant <[hidden email]> wrote:
Hi,

The question of thenables came back on Mozilla's Bugzilla [1] (see comment 29 & 30) with a decent share of skepticism that I share too.

I'm sorry I didn't go through all the promises discussions, but what's the rationale of supporting thenables? I fear this feature won't be necessary 2 or 3 years after native promises ship. For sure, it's of no use to those who only use native promises.

I read from the meeting notes that it was pretty much the only point of debate and a long one.

There was no long debate about thenables, only two requests for clarification of their meaning and one request for explanation of their backing store mechanism, all with immediate responses. The notes reflect exactly that.

I can't speak for Anne, with regard to comment#30, but I don't recall him sharing any kind of skepticism during the conversation. Hopefully he will clarify for us.

Rick

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Mark S. Miller-2
On Thu, Oct 10, 2013 at 3:39 PM, Rick Waldron <[hidden email]> wrote:

On Thu, Oct 10, 2013 at 6:26 PM, David Bruant <[hidden email]> wrote:
Hi,

The question of thenables came back on Mozilla's Bugzilla [1] (see comment 29 & 30) with a decent share of skepticism that I share too.

I'm sorry I didn't go through all the promises discussions, but what's the rationale of supporting thenables? I fear this feature won't be necessary 2 or 3 years after native promises ship. For sure, it's of no use to those who only use native promises.

I read from the meeting notes that it was pretty much the only point of debate and a long one.

There was no long debate about thenables, only two requests for clarification of their meaning and one request for explanation of their backing store mechanism, all with immediate responses. The notes reflect exactly that.

yes.
 
I can't speak for Anne, with regard to comment#30, but I don't recall him sharing any kind of skepticism during the conversation. Hopefully he will clarify for us.

Anne can correct me if I'm wrong, but I don't see any skepticism expressed in comment 30 <https://bugzilla.mozilla.org/show_bug.cgi?id=879245#c30>. It's a reply to Jonas' 29. Interleaving the two:

Jonas:  So the spec ended up with support for thenables after all? Rather than just doing branding :(
 
Anne: Yes
 
Jonas: I take it in order to be compatible with currently existing libraries?
 
Anne: yes
 
Jonas: I guess if that's what TC39 decided on then that's what we should do. But I'm definitely saddened by it. Like you say, the past is shorter than the future.
 
Anne: agreed.

I would have given Jonas the same answers. We agreed to thenable assimilation for reasons that have been endlessly discussed. During the process, everyone deeply involved always wished thenable assimilation wasn't needed. But it is what we agreed to. We declared an official TC39 consensus. There are now several implementation efforts already proceeding based on that consensus -- probably many more than we know of. This is not skepticism. It is agreeing that "that's what we should do" while sharing Jonas' sadness.


--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

David Bruant-5
Le 11/10/2013 01:19, Mark S. Miller a écrit :
On Thu, Oct 10, 2013 at 3:39 PM, Rick Waldron <[hidden email]> wrote:

On Thu, Oct 10, 2013 at 6:26 PM, David Bruant <[hidden email]> wrote:
Hi,

The question of thenables came back on Mozilla's Bugzilla [1] (see comment 29 & 30) with a decent share of skepticism that I share too.

I'm sorry I didn't go through all the promises discussions, but what's the rationale of supporting thenables? I fear this feature won't be necessary 2 or 3 years after native promises ship. For sure, it's of no use to those who only use native promises.

I read from the meeting notes that it was pretty much the only point of debate and a long one.

There was no long debate about thenables, only two requests for clarification of their meaning and one request for explanation of their backing store mechanism, all with immediate responses. The notes reflect exactly that.

yes.
 
I can't speak for Anne, with regard to comment#30, but I don't recall him sharing any kind of skepticism during the conversation. Hopefully he will clarify for us.

Anne can correct me if I'm wrong, but I don't see any skepticism expressed in comment 30 <https://bugzilla.mozilla.org/show_bug.cgi?id=879245#c30>. It's a reply to Jonas' 29. Interleaving the two:

Jonas:  So the spec ended up with support for thenables after all? Rather than just doing branding :(
 
Anne: Yes
 
Jonas: I take it in order to be compatible with currently existing libraries?
 
Anne: yes
 
Jonas: I guess if that's what TC39 decided on then that's what we should do. But I'm definitely saddened by it. Like you say, the past is shorter than the future.
 
Anne: agreed.

I would have given Jonas the same answers. We agreed to thenable assimilation for reasons that have been endlessly discussed. During the process, everyone deeply involved always wished thenable assimilation wasn't needed. But it is what we agreed to. We declared an official TC39 consensus. There are now several implementation efforts already proceeding based on that consensus -- probably many more than we know of. This is not skepticism. It is agreeing that "that's what we should do" while sharing Jonas' sadness.
Alright, let's do this then. Sorry for re-hashing.

Thanks for your answers,

David

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why thenables?

Ѓорѓи Ќосев
I understand that adding branding to promises is impossible at this
point, as it would break backward compatibility with all existing
implementations.

However, thenable assimilation could still be made slightly less sad by
doing something very similar to branding, without breaking backward
compatibility.

The assimilation procedure could check if the thenable has a property
that brands it non-assimilatable, e.g. __notPromise__ If such a property
exists and is set to true, it will not assimilate it.

While far from perfect, this will at least allow objects from existing
libraries that have a .then method to coexist with promises without
forcing library authors (and users) to massively refactor their code.
Authors would only need to add the flag __notPromise__ to their
prototypes - all other existing code will continue to work normally.

I believe this would be better than globally banning such a generic name
like `.then` as a method.

As a bonus, statis analysis tools could possibly warn users to
explicitly add `__notPromise__ = false;` (i.e. they could advise users
to explicitly express intent WRT to assimilation)

Does this sound like a good idea?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why thenables?

Alex Russell-4
On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев <[hidden email]> wrote:
I understand that adding branding to promises is impossible at this
point, as it would break backward compatibility with all existing
implementations.

That wasn't the overriding consdieration. I don't care if we don't have a-priori compatibility. The bigger issue is the lack of symbol infrastructure in the language and the inability to polyfill if we do. I've long argued for "ghetto branding" (something less foot-gun-ish than an extractable then callable), but in the interest of harmony, was not willing to fight for the better design at the end.

Our primary goal here needs to be shipping something ASAP. All other concerns are, in the scheme of things, irrelevant.'

We're already half a year late on this.
 
However, thenable assimilation could still be made slightly less sad by
doing something very similar to branding, without breaking backward
compatibility.

The assimilation procedure could check if the thenable has a property
that brands it non-assimilatable, e.g. __notPromise__ If such a property
exists and is set to true, it will not assimilate it.

While far from perfect, this will at least allow objects from existing
libraries that have a .then method to coexist with promises without
forcing library authors (and users) to massively refactor their code.
Authors would only need to add the flag __notPromise__ to their
prototypes - all other existing code will continue to work normally.

I believe this would be better than globally banning such a generic name
like `.then` as a method.

As a bonus, statis analysis tools could possibly warn users to
explicitly add `__notPromise__ = false;` (i.e. they could advise users
to explicitly express intent WRT to assimilation)

Does this sound like a good idea?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why thenables?

Andrea Giammarchi-2
Alex can I ask you if there's any specific deadline you are talking about?

Your answer sounds like "rushed is better than nothing" ... which usually might/kinda works for web-agencies but not for "would like to be corporate ready/oriented specifications", right ?

Sorry but I think that should be slightly ;-) more elaborated, if possible, thanks.

Quick One for Ѓорѓи : markdown is awesome but in this very specific ML I find easier to read `**notPromise**` when bold is meant, than `__notPromise__` ... you know, `__proto__` and sh...tuff ^_^ unless you didn't really mean `__notPromise__` where in such case I think the `tick` should do it - sorry for the Off Topic, I was just reading through

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why thenables?

Alex Russell-4


On 18 Dec 2013 18:20, "Andrea Giammarchi" <[hidden email]> wrote:
>
> Alex can I ask you if there's any specific deadline you are talking about?

Promises aren't important. They are a tool. And the design space is *clearly* overconstrained. Anyone paying attention can see that. We should have given rough consensus blessing in april and not have deprived ourselves of promises as a tool in API design for the last 7 months as a result.

> Your answer sounds like "rushed is better than nothing" ... which usually might/kinda works for web-agencies but not for "would like to be corporate ready/oriented specifications", right ?

No. Not with overconstrained API that is clearly a bridge to syntax, not a final destination.

This committee has committed half a year of lost opportunities *for the entire platform* on the basis of pathological standards behaviour. This group has poor facility with the costs because we are far too disconnected from our users.

And no. I am not happy.

> Sorry but I think that should be slightly ;-) more elaborated, if possible, thanks.
>
> Quick One for Ѓорѓи : markdown is awesome but in this very specific ML I find easier to read `**notPromise**` when bold is meant, than `__notPromise__` ... you know, `__proto__` and sh...tuff ^_^ unless you didn't really mean `__notPromise__` where in such case I think the `tick` should do it - sorry for the Off Topic, I was just reading through


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Ѓорѓи Ќосев
In reply to this post by Alex Russell-4
On 12/19/2013 02:56 AM, Alex Russell wrote:
On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев <[hidden email]> wrote:
I understand that adding branding to promises is impossible at this
point, as it would break backward compatibility with all existing
implementations.

That wasn't the overriding consdieration. I don't care if we don't have a-priori compatibility. The bigger issue is the lack of symbol infrastructure in the language and the inability to polyfill if we do. I've long argued for "ghetto branding" (something less foot-gun-ish than an extractable then callable), but in the interest of harmony, was not willing to fight for the better design at the end.

This doesn't need symbols at all, and it could be considered a "bugfix" addition - there is still time for those, I believe?
 
It would make `.then` in the method name position less of a language keyword. Without breaking compatibility with existing implementations. It will also pave the path towards a future where most implementations inherit from built in promises and those that don't set their `prototype.__notPromise__ = false`,

If (and when) such a future arrives, the switch can be potentially flipped to assume `true` instead of `false`, thereby essentially removing the quirk from the language - completely.

> Our primary goal here needs to be shipping something ASAP. All other concerns are, in the scheme of things, irrelevant.'
>
> We're already half a year late on this.

Should the language really ban all objects from using `.then`, forever? Should it force library authors to face the decision:

- my objects remain incompatible with promises (cannot be returned by them), or
- rename `.then` method, do a massive refactor, also force all my users to do a massive refactor

Why not provide a harmless third option?

- add __notPromise__ flag to my prototype to tell promises not to assimilate these objects


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Alex Russell-4


On 18 Dec 2013 20:27, "Ѓорѓи Ќосев" <[hidden email]> wrote:
>
> On 12/19/2013 02:56 AM, Alex Russell wrote:
>>
>> On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев <[hidden email]> wrote:
>>>
>>> I understand that adding branding to promises is impossible at this
>>> point, as it would break backward compatibility with all existing
>>> implementations.
>>
>>
>> That wasn't the overriding consdieration. I don't care if we don't have a-priori compatibility. The bigger issue is the lack of symbol infrastructure in the language and the inability to polyfill if we do. I've long argued for "ghetto branding" (something less foot-gun-ish than an extractable then callable), but in the interest of harmony, was not willing to fight for the better design at the end.
>>
> This doesn't need symbols at all, and it could be considered a "bugfix" addition - there is still time for those, I believe?
>  
> It would make `.then` in the method name position less of a language keyword. Without breaking compatibility with existing implementations. It will also pave the path towards a future where most implementations inherit from built in promises and those that don't set their `prototype.__notPromise__ = false`,
>
> If (and when) such a future arrives, the switch can be potentially flipped to assume `true` instead of `false`, thereby essentially removing the quirk from the language - completely.
>
>
> > Our primary goal here needs to be shipping something ASAP. All other concerns are, in the scheme of things, irrelevant.'
> >
> > We're already half a year late on this.
>
> Should the language really ban all objects from using `.then`, forever? Should it force library authors to face the decision:
>
> - my objects remain incompatible with promises (cannot be returned by them), or
> - rename `.then` method, do a massive refactor, also force all my users to do a massive refactor
>
> Why not provide a harmless third option?
>
> - add __notPromise__ flag to my prototype to tell promises not to assimilate these objects

That's an inverse form of "ghetto branding". But it doesn't matter either. The only thing that does is having *one*, *standard* contract -- and we are past due on that.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why thenables?

Andrea Giammarchi-2
In reply to this post by Alex Russell-4
Thanks for the clarification and FWIW, yeah ... I agree with you but I also appreciate the effort everyone is putting trying to bring new features that are as platform agnostic as possible ... but then again, we have real life/devs/code screaming for solutions ASAP

Devs also complain about mistakes though .. not sure how to win here :-(

Cheers


On Wed, Dec 18, 2013 at 8:18 PM, Alex Russell <[hidden email]> wrote:


On 18 Dec 2013 18:20, "Andrea Giammarchi" <[hidden email]> wrote:
>
> Alex can I ask you if there's any specific deadline you are talking about?

Promises aren't important. They are a tool. And the design space is *clearly* overconstrained. Anyone paying attention can see that. We should have given rough consensus blessing in april and not have deprived ourselves of promises as a tool in API design for the last 7 months as a result.

> Your answer sounds like "rushed is better than nothing" ... which usually might/kinda works for web-agencies but not for "would like to be corporate ready/oriented specifications", right ?

No. Not with overconstrained API that is clearly a bridge to syntax, not a final destination.

This committee has committed half a year of lost opportunities *for the entire platform* on the basis of pathological standards behaviour. This group has poor facility with the costs because we are far too disconnected from our users.

And no. I am not happy.

> Sorry but I think that should be slightly ;-) more elaborated, if possible, thanks.
>
> Quick One for Ѓорѓи : markdown is awesome but in this very specific ML I find easier to read `**notPromise**` when bold is meant, than `__notPromise__` ... you know, `__proto__` and sh...tuff ^_^ unless you didn't really mean `__notPromise__` where in such case I think the `tick` should do it - sorry for the Off Topic, I was just reading through



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Ѓорѓи Ќосев
On Thu 19 Dec 2013 07:42:31 AM CET, Andrea Giammarchi wrote:

> The only thing that does is having *one*, *standard* contract -- and we are past due on that.

Perhaps the right path would be to try and discuss this for
Promises/A++, and maybe if it happens there, ES7 afterwards :)

> Devs also complain about mistakes though .. not sure how to win here :-(

No worries. I think I understand now. Still I felt it was worth a shot,
although I guess I picked the wrong path (and time) to go about it.

Thanks for your time -- and sorry for creating a stir.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Mark S. Miller-2
I think this anti-branding idea is worth considering, but using a symbol or weakmap for the anti-branding rather than a magic double-underbar property name. Unlike prior positive thenable branding proposals, this one doesn't break existing code but still provides systems that use "then" in contrary ways an ability to cope. It also doesn't break anything premised on the promise-unwrapping consensus that we've agreed on and specced. I see only two questions:

* Whether the benefit is worth the additional complexity?
* If we do decide to do this, does it make sense to postpone it to ES7?

Unless there is significant demonstrated need, I am leaning away from the paying the additional complexity. OTOH, since this would mainly be about mitigating the pain of fixing contrary uses of "then", if we're going to do it at all, we should do it in ES6. If we don't, then these contrary uses of "then" will probably already be fixed by the time ES7 rolls out.



On Thu, Dec 19, 2013 at 9:03 AM, Ѓорѓи Ќосев <[hidden email]> wrote:
On Thu 19 Dec 2013 07:42:31 AM CET, Andrea Giammarchi wrote:

> The only thing that does is having *one*, *standard* contract -- and we are past due on that.

Perhaps the right path would be to try and discuss this for
Promises/A++, and maybe if it happens there, ES7 afterwards :)

> Devs also complain about mistakes though .. not sure how to win here :-(

No worries. I think I understand now. Still I felt it was worth a shot,
although I guess I picked the wrong path (and time) to go about it.

Thanks for your time -- and sorry for creating a stir.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Ѓорѓи Ќосев
On Thu 19 Dec 2013 06:24:50 PM CET, Mark S. Miller wrote:
> I think this anti-branding idea is worth considering, but using a
> symbol or weakmap for the anti-branding rather than a magic
> double-underbar property name. Unlike prior positive thenable branding
> proposals, this one doesn't break existing code but still provides
> systems that use "then" in contrary ways an ability to cope. It also
> doesn't break anything premised on the promise-unwrapping consensus
> that we've agreed on and specced.

Thanks :)

> I see only two questions:
>
> * Whether the benefit is worth the additional complexity?
> * If we do decide to do this, does it make sense to postpone it to ES7?
>
> Unless there is significant demonstrated need, I am leaning away from
> the paying the additional complexity.

This anti-branding proposal is not just about making the
immediate future smoother. My hope is that it could potentially provide
a path for the far future where research can be done to determine
whether compatibility issues are still there. If they aren't, Promises
could start assuming that object[notPromiseSymbol] === true, (unless
explicitly stated otherwise). This practically means completely
removing the wart from the language except for promise authors that
don't extend the built-in Promise (or for those that actually *want*
automatic thenable assimilation of their non-promises)

I feel that right now the `then` method is a bit worse than a keyword.
Unlike
keywords, it may cause random hard to find bugs and unpredictable
behaviour
(instead of syntax errors) for unsuspecting users. That makes any path
that can
potentially make it unreserved worth pursuing, at any time (now or in
the future).

The complexity cost is not much greater than regular branding for
implementers. The complexity cost is not much greater for end-users
either - in both cases they will still have to know that `.then` is
special (albiet in the latter case case, still available, and
potentially not special at all in the future).

And in the latter case, cognitive load can potentially be reduced for
users.
Its easier to make a static analysis tool that warns them to explicitly
set
this[notPromiseSymbol] to either true or false when a then method is
detected.

Whereas without the anti-brand, the tool would have no idea whether the
user
really wants automatic assimilation, or they're just unaware of the
special
behaviour.

> OTOH, since this would mainly be
> about mitigating the pain of fixing contrary uses of "then", if we're
> going to do it at all, we should do it in ES6.

Right - thats why I tried suggesting it now... But still, I think that
there are
enough reasons to do this even if after the ES6 ship sails.

> If we don't, then these contrary uses of "then" will probably already be
> fixed by the time ES7 rolls out.

I'm sorry, but I cannot accept the claim that there is such a thing as
"contrary use of then". Libraries are not at fault here - ES6 is the
one trampling
on their use of a perfectly valid, very generic method name.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Alex Russell-4
In reply to this post by Mark S. Miller-2
On Thu, Dec 19, 2013 at 9:24 AM, Mark S. Miller <[hidden email]> wrote:
I think this anti-branding idea is worth considering, but using a symbol or weakmap for the anti-branding rather than a magic double-underbar property name. Unlike prior positive thenable branding proposals, this one doesn't break existing code but still provides systems that use "then" in contrary ways an ability to cope.

...but only in an unpolyfillable, ES6-only world.

What in the heck are we smoking if we decided that thenables were the right thing to do but we should lean on unavailable tech to do the contra? How could we POSSIBLY talk ourselves into that in good faith?

This has ventured into farce. I pray it stops.
 
It also doesn't break anything premised on the promise-unwrapping consensus that we've agreed on and specced. I see only two questions:

* Whether the benefit is worth the additional complexity?
* If we do decide to do this, does it make sense to postpone it to ES7?

Unless there is significant demonstrated need, I am leaning away from the paying the additional complexity. OTOH, since this would mainly be about mitigating the pain of fixing contrary uses of "then", if we're going to do it at all, we should do it in ES6. If we don't, then these contrary uses of "then" will probably already be fixed by the time ES7 rolls out.



On Thu, Dec 19, 2013 at 9:03 AM, Ѓорѓи Ќосев <[hidden email]> wrote:
On Thu 19 Dec 2013 07:42:31 AM CET, Andrea Giammarchi wrote:

> The only thing that does is having *one*, *standard* contract -- and we are past due on that.

Perhaps the right path would be to try and discuss this for
Promises/A++, and maybe if it happens there, ES7 afterwards :)

> Devs also complain about mistakes though .. not sure how to win here :-(

No worries. I think I understand now. Still I felt it was worth a shot,
although I guess I picked the wrong path (and time) to go about it.

Thanks for your time -- and sorry for creating a stir.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Ѓорѓи Ќосев

...but only in an unpolyfillable, ES6-only world.

 
Right, they don't help existing libraries, but it would still pave a path towards branded-only promises in the (unfortunately very, very far) future (with ES5 all but gone)

Only "ghetto anti-branding" will help existing libraries (and make it possible to check if flipping the switch is okay much earlier).

Its not like combining ghetto .then with ghetto `__notPromise__` is worse than just ghetto `then`. One thing that can be done is to make it less ugly. Since it would always be checked in tandem with `then`, it could simply be `notConvertableToPromise`.  Without the double underscores, people will be slightly less likely to ask "what the hell were they smoking"


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Alex Russell-4
Right, but number of objects you have to guard with anti-branding is much, much larger. That argues against thenables pretty strongly, but again, I don't think we need to change anything for ES6. We can repair this in ES7 if it's a problem in practice.


On Thu, Dec 19, 2013 at 2:21 PM, Gorgi Kosev <[hidden email]> wrote:

...but only in an unpolyfillable, ES6-only world.

 
Right, they don't help existing libraries, but it would still pave a path towards branded-only promises in the (unfortunately very, very far) future (with ES5 all but gone)

Only "ghetto anti-branding" will help existing libraries (and make it possible to check if flipping the switch is okay much earlier).

Its not like combining ghetto .then with ghetto `__notPromise__` is worse than just ghetto `then`. One thing that can be done is to make it less ugly. Since it would always be checked in tandem with `then`, it could simply be `notConvertableToPromise`.  Without the double underscores, people will be slightly less likely to ask "what the hell were they smoking"


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Andreas Rossberg-4
On 19 December 2013 23:29, Alex Russell <[hidden email]> wrote:
> Right, but number of objects you have to guard with anti-branding is much,
> much larger. That argues against thenables pretty strongly, but again, I
> don't think we need to change anything for ES6. We can repair this in ES7 if
> it's a problem in practice.

I highly doubt that will be possible -- experience strongly suggests
that every odd feature _will_ be relied on in the wild by that time.
If we think thenable assimilation is a problem then we have to remove
it now. I, for one, would welcome that. We could still provide an
_explicit_ thenable adaptor method in the Promise API.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Mark S. Miller-2
Thenable assimilation is already used in the wild to a degree that we can't break. I agree with Alex that we should not re-litigate this. It is only anti-branding that could be added later -- and only if there's evidence of a need great enough to justify the added complexity. In the absence of that evidence, let's just stick to the consensus we've already achieved.



On Fri, Dec 20, 2013 at 5:02 AM, Andreas Rossberg <[hidden email]> wrote:
On 19 December 2013 23:29, Alex Russell <[hidden email]> wrote:
> Right, but number of objects you have to guard with anti-branding is much,
> much larger. That argues against thenables pretty strongly, but again, I
> don't think we need to change anything for ES6. We can repair this in ES7 if
> it's a problem in practice.

I highly doubt that will be possible -- experience strongly suggests
that every odd feature _will_ be relied on in the wild by that time.
If we think thenable assimilation is a problem then we have to remove
it now. I, for one, would welcome that. We could still provide an
_explicit_ thenable adaptor method in the Promise API.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why thenables?

Ѓорѓи Ќосев
In reply to this post by Andreas Rossberg-4
On 12/20/2013 02:02 PM, Andreas Rossberg wrote:
> On 19 December 2013 23:29, Alex Russell <[hidden email]> wrote:
>> Right, but number of objects you have to guard with anti-branding is
much,
>> much larger. That argues against thenables pretty strongly, but again, I
>> don't think we need to change anything for ES6. We can repair this in
ES7 if
>> it's a problem in practice.

Will this be shimmable (by monkey patching) in ES6 in a way that enables
all promises (even those produced by the DOM) to have the new behavior?

The objects you have to guard with anti-branding are only those who have
a .then method and are not promises. True, its nowere nearly good as
branding. However, its still better than making ".then" a complete
taboo. At least the library authors get *some* say on the matter.

This is how I imagine things happening:

Lets say the anti-branding property is called "convertableToPromise" and
that the value "true" is assumed if the property is not defined on the
thenable.

Lets just not even call it anti-branding - its just a marker.

Example 1:

A library author that is not very familiar with all the intricacies of
promises writes a code parsing/transformation library that uses .then as
a method of chaining different transformations. It turns out to be
widely popular, and a library user wants to create a parser for remotely
downloaded code. The library user fires a download operation and gets a
promise, creates a transformed promise by adding a .then callback, and
attempts to return the parser from within the then callback. Everything
breaks.

Solutions available without anti-branding:

- the author of the library must rename .then and must tell every single
person depending on that library to refactor to the new method
- the author declares the library incompatible with promises.

note: A lint tool *cannot* reliably warn them about it, because it
cannot tell whether they want thenable assimilation or not (whether the
class they are writing represents a "promise" or not)

Solution available with anti-branding
- the author of the library adds `Parser.prototype.convertableToPromise
= false;`. Everything starts working.

Even better, the library user can also likely do this.

note: A lint tool can warn them about it before the library becomes
popular, avoiding the troublesome situation in the first place.


Example 2:

A library author wants to write a library for a new kind of functional
asynchrony abstraction. They actually *do* want promises to be able to
assimilate this asynchrony, so they add a method called .then. Since
they are quite familiar with asynchronous code (and therefore likely
with promises) they know that even though they don't have to, they can add:

`Asynchrony.prototype.convertableToPromise = true;`

to explicitly state that this object is infact convertable to a promise.
A lint tool or an IDE can even warn them about it and they will add it
to make the tool stop complaining.


Hopeful far future outcome:

ES7 arrives. Most promise libraries inherit from the built-in Promise,
and the semantics of `convertableToPromise` are well understood by those
who write async code. Therefore its possible to test whether its okay to
flip the default value of `thenable.convertableToPromise` to false. If
its determined that this would cause too much breakage at that
particular moment, the decision is postponed again for ES8.

If at any point its determined that its possible to flip this switch,
the "thenable wart" will be forever removed from the language.

>
> I highly doubt that will be possible -- experience strongly suggests
> that every odd feature _will_ be relied on in the wild by that time.
> If we think thenable assimilation is a problem then we have to remove
> it now. I, for one, would welcome that. We could still provide an
> _explicit_ thenable adaptor method in the Promise API.

But this will make promises created by existing promise libraries
incompatible with built-in promises. It will cause the same problem, but
in reverse. Yes, hopefully library authors will add the branding to
their promise libraries, and hopefully after a while everything will
start working except legacy code, but its still a worse outcome.

That is why I proposed anti-branding - as a compromise.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12