Naming

[kelunik]

I still prefer Promise over Whenable. It will be the name that's used in type declarations where multiple implementations may occur. Everyone familiar with these things knows what a promise is. I think the name expresses more a concept than a particular API, so it's perfectly fine to use it with when even if Promises/A+ has then.

[bwoebi]

Awaitable is fine for me too (besides Promise), but I dislike Whenable.

[WyriHaximus]

Where Awaitable and Promise provide a unambiguous meaning, Whenable feels awkward imho

[kelunik]

@WyriHaximus FWIW it's just the same as Thenable.

[bwoebi]

Thenable feels IMHO awkward too…

[DaveRandom]

able is a verb suffix (walkable, drinkable, breakable, lickable). Neither "when" nor "then" are verbs.

Promise (in this context) is a noun, and await is a verb. "This promise is awaitable" is fine and doesn't invent any new words or turn any words into things they aren't already.

_{Source: I am a native English speaker and a really annoying pedant}

[kelunik]

@DaveRandom If we care about nouns and verbs, we should probably make the method a verb as well, uggestions? Promise::on? Not actually a verb, but rather like an event. In Loop we also use on.

[DaveRandom]

@kelunik I had no strong opinions about it the other day, but that it a solid argument for

when($promise, $callback) // when this promise resolves, invoke this callback

But also, await()...

[kelunik]

await() is a bad choice, since invoking the method doesn't await it, it just registers a callback.

[bwoebi]

^{@DaveRandom You're not annoying :-P}
@kelunik what's wrong with when()? It's a temporal reference and that's fine. onReadable etc. are temporal references too.

[rdlowrey]

Awaitable doesn't make sense to me because it only describes one action you can take using the placeholder value for which an async lib has promised future resolution. Semantically it's not a good description of the essence of the thing. More thoughts on that here:

http://chat.stackoverflow.com/transcript/11/2016/5/15

Also: @DaveRandom you're pedantry is hilarious and makes it easier to wake up in the morning.

[WyriHaximus]

ping @jsor

[kelunik]

preference for Promise over Awaitable because we don't actually have to wait on the future resolution of an async operation – http://chat.stackoverflow.com/transcript/11/2016/5/15

It says Awaitable, so you don't have to wait for it. I just think Promise is the more common term used and one that people are familiar with.

But I'd be fine with both.

[trowski]

I'm not really a fan of Whenable either. I thought @kelunik and @bwoebi preferred it over Awaitable, but evidently I misunderstood in chat. I'll wait to update it again until we reach a consensus here.

Promise bothers me because what we're proposing is not a promise that people are familiar with. Promises are suppose to be "thenable", or have a then() method conforming to the Promises/A+ spec. If the interface isn't going to offer this method, then it shouldn't be called Promise. I feel we could avoid future bikeshedding arguments by just picking a different name.

If Awaitable is unacceptable, then lets pick something more generic such as Future or Delayed. In this case I'd vote for Future. We have an object representing a future event or data, with a method to execute callbacks when that future event occurs or data is available.

[bwoebi]

Haha, funny that you propose Future … https://github.com/amphp/amp/blob/v0.15.0/lib/Future.php That was actually the original name we had used in Amp … I obviously don't object - we actually had moved the name to Promise as this was more commonly known [mainly from people coming from JS].

I'm fine with Future too. [Delayed is a bit too generic and I don't immediately recognize its role.]

[kelunik]

That was actually the original name we had used in Amp

Yes, but not for Promise but for Deferred.

[bwoebi]

@kelunik not exactly, we had Future implementing both Promise and Promisor.

[bwoebi]

hmm … actually … In different programming languages Future, Promise etc. are used for different things :-/ …

[trowski]

@bwoebi Promise and Future are certainly defined differently in various programming languages. However, as PHP is a web-centric language and Promise is usually an object with a then() method in JS, Python, Ruby, and many existing PHP implementations, then I feel it is best to avoid Promise and go with a name without as many assumptions about interface, such as Future.

[sagebind]

I prefer Awaitable over everything else, since one of the actions (perhaps one of the most interesting ones) is that you can "await" on it.

I don't prefer Promise, especially if we aren't going to have a then() method. People might confuse it with promise interfaces in JavaScript or other languages, but then not conforming the the same de-facto interface might be misleading.

Future would be acceptable. I don't have strong opinions on that one, except that it is a common name used in other languages for a similar concept.

I don't like Whenable for the exact reasons @DaveRandom outlined.

[kelunik]

I prefer Awaitable over everything else, since one of the actions (perhaps one of the most interesting ones) is that you can "await" on it.

What bothers me is that you don't really await it, you just register a callback to its resolution event. "Wait" has some sort of blocking association.

[jsor]

I have a preference for Promise or Future over Awaitable and Whenable for the same reasons @trowski and @rdlowrey mentioned.

[kelunik]

@jsor: Uhm, @trowski didn't mention a preference for Promise, he doesn't like Promise because of it's then API that's known to others.

[kelunik]

See also https://en.wikipedia.org/wiki/Futures_and_promises. It's an old term, it's not coupled to a specific API like then.

My very minor issue with Future is that it might also be now, see https://github.com/amphp/amp/blob/master/lib/Success.php for an example.

[bwoebi]

That's why Future should be the name of the Promisor: the Instance promising future resolution of the Promise.

[kelunik]

Correct, Future or Deferred there.

[jsor]

@kelunik Yeah sorry, i meant the arguments of @trowski for Future and the arguments of @rdlowrey for Promise. I have no strong preference between Promise and Future, but for the two over Awaitable and Whenable.

[kelunik]

I tried to summarize, I might be wrong with + / 0 or 0 / -, but overall it should be fine.
https://gist.github.com/kelunik/9e2e708010c926fca17dfc646264f630

If you change your opinion or aren't in there yet, just ping me.

[bwoebi]

Set me as -1 on Future (for Promise). I'm +1 for it as Promisor class name, but that's out of scope here.
Also 0 for Awaitable.

[kelunik]

HHVM also uses Awaitable: https://docs.hhvm.com/hack/reference/interface/HH.Awaitable/

If we're going to use await later in PHP, that's probably the best name.

[kelunik]

I updated my draft to use Awaitable and also updated the gist with + / 0 / -.
https://gist.github.com/kelunik/9bd92e23c4b734b457c610acf7393b98

[bwoebi]

@kelunik actually, it seems like we have the least opposition and most in favor for Promise, not Awaitable?

[joshdifabio]

There seems to be general consensus around the implementations of thenable and whenable, but not the names of the interfaces; maybe you guys should take a vote on the names or set a date by which you think that should happen, since it's quite a subjective issue? Just a suggestion.

[kelunik]

@joshdifabio We will eventually, but I think we can defer that until we have the event loop ready. There's still discussion and changing votes for it currently.

@bwoebi: @rdlowrey's feeling about Awaitable is much better if we have await later in the language, then it's not true anymore.

@jsor How do you feel about Awaitable if you think about it's usage in combination with await?

@joshdifabio What's your preference? I'd be happy to add it to the table.

[kelunik]

@trowski: I think the important assumption of Promise is chainability, not a then method, talked to unrelated people today knowing them from jQuery and other JS libraries, but didn't ever use them in PHP.

[jsor]

@kelunik Awaitable is totally ok for me. The others were just a preference.

[bwoebi]

Even if we'll have await, it still sounds logical to me to await a Promises resolution.

@kelunik yeah, Amp Promises are chainable, i.e. they return themselves on when(). Maybe we shall require this here too?

[joshdifabio]

@kelunik yeah, Amp Promises are chainable, i.e. they return themselves on when(). Maybe we shall require this here too?

Not in the same way that Promises/A+ promises are chainable. I think that what @kelunik is saying is that people tend to assume Promises/A+ when they hear promise.

@joshdifabio What's your preference? I'd be happy to add it to the table.

It's so subjective that I don't think I can add anything here.

It's worth considering that the naming issue only exists because there are two rival promise implementations being proposed. If these interfaces were merged (the pragmatic solution) or one was favoured (probably a question of who can shout the loudest) we'd get around the whole naming issue, since we could simply define a single Promise interface. Also consider the amount of time developers are cumulatively likely to waste in repeatedly having to decide shall I return a thenable or a whenable?, and the amount of CPU time wasted in converting whenables to thenables and vice versa. Just thinking aloud!

[kelunik]

@joshdifabio The implementation is clearly Amp's, but people don't seem to agree on Amp's name for it. So that doesn't bring us anything. We have two issues: A name and the implementation.

[joshdifabio]

@joshdifabio The implementation is clearly Amp's, but people don't seem to agree on Amp's name for it. So that doesn't bring us anything. We have two issues: A name and the implementation.

If you are saying that thenable will be dropped in favour of whenable then I would say whenable should be named Promise. To clarify my previous point: I was trying to say that, if the intention is to support both thenable and whenable, then maybe they should be merged into a single Promise interface with two methods: when and then: easy to implement, interoperable, and users can easily create promise chains or use coroutines (efficiently) depending on their preference, without having to convert between the two.

[kelunik]

@joshdifabio: @rdlowrey suggested that too some minutes ago. I hope then will eventually die in favor of co-routines, so I don't like building it into the spec. Implementations can always provide then additionally.

[joshdifabio]

@joshdifabio: @rdlowrey suggested that too some minutes ago. I hope then will eventually die in favor of co-routines, so I don't like building it into the spec.

I absolutely prefer to use coroutines as well. If everyone here agreed on that point then I suppose it would make everything a bit simpler, but if that doesn't happen then what's the next best thing? Maybe it is to keep them separate, but maybe it's not.

Implementations can always provide then additionally.

Such implementations would have to specify their own classes or interfaces as return types, instead of the interop interfaces. I don't think that's what anyone wants.

[bwoebi]

There is absolutely no problem with return typing your specific interface/class.
And inside applications you don't need the interop, as long as there's an easy utility function to convert from interop to specific class.
Interop is mainly important between libraries.

[kelunik]

Such implementations would have to specify their own classes or interfaces as return types, instead of the interop interfaces. I don't think that's what anyone wants.

We we don't target PHP 7, you don't have a return type declaration anyway. Covariance is perfectly fine.

@bwoebi We really need covariant return types.

[joshdifabio]

And inside applications you don't need the interop, as long as there's an easy utility function to convert from interop to specific class.
Interop is mainly important between libraries.

This seems like quite an arbitrary and unscientific claim. A utility function for converting promises can clearly be used to solve the promise interoperability issue at any level, whether that be the application level or the library level. The issue is that it's a suboptimal solution which results in a lot of boilerplate code and wasted CPU cycles. That doesn't stop being the case at the application level.

[kelunik]

@joshdifabio I think you missed the point. Usually when should be enough, because most promises should be used in co-routines only. These are always interoperable.

A utility function for converting promises can clearly be used to solve the promise interoperability issue at any level

It can also be used now, sure, but currently you have n different implementations which you have to convert to the one you want. If we have when standardized, you only need a single when to convert it. You will always get an Awaitable. And you only need this if you really want to chain it using then or something like that.

[jsor]

@joshdifabio I don't think it makes much sense to include then in the interface because you would then be limited to this method when consuming Awaitable's directly. You'd loose all the shortcut and syntactic sugar stuff libraries like Icicle\Awaitable, guzzle/promises and react/promise provide (like done, capture/otherwise etc.). So, you need to pass it through resolve() anyway.

[trowski]

It appears after all this discussion that we are back where we started with Awaitable. 😝

Hack uses Awaitable as it's placeholder primitive and would seem a likely candidate when await is (hopefully) added to PHP.

@joshdifabio The intention is to drop the proposal for any "thenable" object with a then method and only standard this interface. Implementations can use when to create then, done, or any of the other methods that exist on current promise libraries such as React\Promise or Icicle\Awaitable, as well as helper functions such as all.

[kelunik]

Seems like we don't have a single voice against Awaitable now. I'm not sure whether @rdlowrey and @jsor are + or 0 now, but that doesn't matter as long as nobody is against it.

I'll post the link again here: Ratings.

If nobody raises a voice against it, I'll close this issue tomorrow and merge the PR @trowski provided.

[jsor]

@kelunik I'm convinced now: you can change my vote to + for Awaitable and 0 for Promise/Future.