PSR for Event Loop and PSR for Promises*

[Christopher Pitt]

Hello fine people!

There are three popular projects implementing slightly different versions of reactive (event-based) architecture, in PHP. And probably a bucket-load of smaller stuff that goes unnoticed. 

- They all implement and Event Loop

- They all implement Promises.

Is there enough desire, within this group, to look at what they are doing and think about forming some standards for these things? They're well-defined already. For instance, we could just choose to ratify (make into rats) Promises A+ in the form of PHP interfaces. And we could think unify the approaches of these reactive projects into a single Event Loop standard. 

*I do think these should be different PSR's (if there's enough interest), because event loops don't need promises and promises don't need event loops. Also bike-shedding is real...

This would pave the way for considering how existing PSR's intersect with asynchronous architectures. 

WHAT SAY YOU?!

Kind regards

Chris

[Jeremy Lindblom]

Guzzle has a Promises/A+ implementation as well, and we would love to see a promise interface as a PSR. We have no interest in an event loop PSR (as far as Guzzle itself goes), so having them separate would be ideal.

--
Jeremy Lindblom (@jeremeamia)
Software Engineer for Engrade (part of McGraw-Hill Education)

President of the Seattle PHP User Group (@seaphp)

Organizer of the Pacific Northwest PHP conference (@pnwphp)

Co-author of the AWS SDK for PHP (@awsforphp)

PHP-FIG Representative for the Guzzle project

Looking for a junior or senior-level software engineering position in PHP? I have some available with McGraw-Hill Education in Seattle and Los Angeles. Contact me for me more information.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b971ac31-7475-4c59-8256-14d370648abd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Larry Garfield]

For my part, this is dependent primarily on the authors of those "big three" you mention.  If the three of them want to unify their interfaces (and I agree that just casting A+ to PHP interfaces is probably best), then I'm happy to have FIG host that discussion/specification.  But I'd want to know that those projects want it/would use it first.

--Larry Garfield

[Christopher Pitt]

@Jeremy: silly me for forgetting to mention Guzzle.

@larry: I'll ask them! :D

[Andrew Carter]

Larry: I chatted to you the other day on IRC about the PHPFastCGI project I've been working on (http://phpfastcgi.github.io/quick-start/).

Ideally I would like to make this project capable of asynchronous IO. I approached Christopher about a PSR because I couldn't think of a way to do this without tightly coupling the project to React or icicle.

The end goal would be that applications could create promises of responses to requests. The promises would, for example, be dependent on the results of asynchronous queries to a database or HTTP requests to an API. That way the server could continue accepting and processing new requests while it was waiting for the data it required to respond to previous ones to become available - without threading.

[Aaron Piotrowski]

Hello! I'm the author of one of the projects Christopher mentioned, Icicle.

I have had some interest in proposing a PSR for a promise interface for some time. I started a repo at https://github.com/thenable/promise with an interface that I would like to use as the basis for the proposal. I recently updated the name to PromiseInterface (as this group requires interfaces to be suffixed by -Interface) as well as adding except() and done() methods to the standard then() method of A+ promises. Many JS implementations include similar methods (usually catch() instead of except(), but we cannot use catch() as a method name in PHP).

I believe each of the libraries Christopher mentioned (plus Guzzle) would be able to implement the interface above without modifying any methods in their current interface, allowing backward compatibility while enabling better interoperability for the future.

Aaron Piotrowski

[Moshe Brevda]

As an said, catch should be usable as a method name in PHP7: http://php.net/manual/en/migration70.other-changes.php

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ecb163e6-0e6a-4c96-8795-c5b9533505e2%40googlegroups.com.

[Evert Pot]

Another implementation from us:

https://github.com/fruux/sabre-event/blob/master/lib/Promise.php

Definitely also interested in a PSR for this. Hopefully we can keep it
simple with *just* implementing Promises A+ in a single interface.

Evert

On 2015-10-08 6:24 PM, Larry Garfield wrote:
> On 10/08/2015 05:19 PM, Christopher Pitt wrote:
>> Hello fine people!
>>

>> There are three <http://reactphp.org/> popular <https://icicle.io/>
>> projects <https://github.com/amphp> implementing slightly different

[Chris Boden]

(copy/paste from other thread):

My opinion reflects that of my own and not React's at this time. 

-1 on Promise PSR. While promises can work with both sync and async paradigms they're geared towards async. Promises can't handle collections of async values. Observables are better in every way to Promises. IF there is to be an official API for handling async data it should be an interface that will work going forward not one that is only capable of single value resolutions. 

[Woody Gilk]

On Thu, Oct 22, 2015 at 8:33 AM, Chris Boden <cbo...@gmail.com> wrote:

Promises can't handle collections of async values.

Can you please explain what you mean by this? Guzzle (maybe others) have ways to resolve a collection of values:

\Guzzle\Promise\all($collection)->then(...);

Works just fine and the promises spec works for any kind of value, not just async. A collection of promises is just another type of structure that can be incrementally resolved.

--
Woody Gilk
http://about.me/shadowhand

[Chris Boden]

Your example is a collection OF individual async values not an async collection. A promise is a SINGLE value that can only be resolved ONCE. Observables can represent both single values and collections; much like a stream but also have error and completion flow. 

[Niklas Keller]

Amp's Promise API allows progress updates, so not just a single value per Promise. However, it's still a single resolution value. https://github.com/amphp/amp/blob/master/lib/Promise.php

But you could also resolve a Promise to an array or a Generator if you need multiple values.

[Chris Boden]

React's Promise (which is an implementation of A+) library also supports notify for updates, however this was an addition and doesn't fit the flow cleanly. Returning an array from a promise is a single value, same problem. Returning a Generator WILL work but then you're working with 2 different APIs and the second isn't explicit, which IMO would defeat the purpose of having a PSR. 

[Jeremy Lindblom]

Chris B.,

Could you point us to PHP project using observables, or if there isn't one, a project in some other language? Maybe some good articles as well? I'm not familiar with observables myself, but I'm interested in learning more. I think promises are awesome, and that they work great for everything that I've done, so I'm curious how observables could improve on that.

Thanks,

--
Jeremy Lindblom (@jeremeamia)
Software Engineer for Engrade (part of McGraw-Hill Education)

President of the Seattle PHP User Group (@seaphp)

Organizer of the Pacific Northwest PHP conference (@pnwphp)

Co-author of the AWS SDK for PHP (@awsforphp)

PHP-FIG Representative for the Guzzle project

Looking for a junior or senior-level software engineering position in PHP? I have some available with McGraw-Hill Education in Seattle and Los Angeles. Contact me for me more information.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/bbd96e38-e325-4fac-80f8-d96108b6808c%40googlegroups.com.

[Chris Boden]

Quick comparison: https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises

In depth introduction: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

The Rx site: http://reactivex.io/  (Rx is a specific implementation)

Rx.PHP: https://github.com/asm89/Rx.PHP

Rx.PHP currently has some amazing work going into it that should be released soon. I'll be updating most/all of my interfaces to it once so. 

[Chris Boden]

Observables in ECMAScript 6: https://github.com/zenparsing/es-observable

Top of Hacker News today: https://realm.io/news/droidcon-gomez-functional-reactive-programming/

[Jonathan Eskew]

JavaScript adopting both promises and observables seems like a strong argument that each has its place. Futures and streams solve different problems.

[Larry Garfield]

Now back on the right thread...

Chris, so are you arguing that having a Promises PSR is actively harmful, or relatively unimportant because we should all switch to Observables anyway?

It seems to me like having standard Promises doesn't preclude Observables, and they clearly do have some benefits here and now, so having a Promises PSR is fine; if we end up making an Observables one in a year or two as well, OK then.

--Larry Garfield

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/cde72023-9b48-46f0-9122-169ed73d88a0%40googlegroups.com.

[Chris Boden]

Yup, that's what I'm suggesting. If something is going to be standardized why not set the best example going forward? Why standardize an interface that is lacking when another exists that can do everything and more?

The A+ specification does not include cancelling promises...they've been debating 4 different implementations for months without end in sight. The progress for collection based async calls is not part of the standard either. 

[Alessandro Pellizzari]

On Thu, 22 Oct 2015 06:33:20 -0700 (PDT)
Chris Boden <cbo...@gmail.com> wrote:

> -1 on Promise PSR. While promises can work with both sync and async
> paradigms they're geared towards async. Promises can't handle
> collections of async values. Observables are better in every way to
> Promises. IF there is to be an official API for handling async data
> it should be an interface that will work going forward not one that
> is only capable of single value resolutions.

I think they are both useful, and I would love to have a standard
promise PSR, but a bit more complete than the A+ one.

Promises are very useful when you need a one-shot signal, and
especially when you need to check several of them at once.

For example, I would love to be able to do something like this:

$pdoPromise = PPDO::connect($dsn);
$filePromise = PFile::open($fileName, 'w');

Promise::when([$pdoPromise, $filePromise]).done(
function($pdo, $file) {
$stmt = $pdo->query(...);
foreach ($stmt as $row) {
fwrite($file, $row);
}
}
);

And being able to use observables for that inner loop would be even
more interesting:

$observableResult = Observable::create($pdo->query(...));
$observableResult->register(function($row) {
fwrite($file, $row);
});


What I propose for promises is an interface like this:

interface Promise {
public function done(callable $fn) : Promise;
public function fail(callable $fn) : Promise;
public function always(callable $fn) : Promise;
}

And possibly

interface Promises {
public static when(Promise[] $promises) : Promise;
}

Or a single interface including both static and normal methods:

interface Promise {
public function done(callable $fn) : Promise;
public function fail(callable $fn) : Promise;
public function always(callable $fn) : Promise;
public static when(Promise[] $promises) : Promise;
}

done() registers a callback to be called when the promise succeeds,
fail() does the same, but for when it fails. always() registers it to be
always called after done/fail callbacks.
when() takes an array of promises and done()s when all of them done(),
and fail()s when even a single one of them fail()s, and the callbacks
receive every promise result as parameters, in order (or an array of
them, you you want "strict typing").


What I don't like of the A+ promises is that you must provide a success
callback, even if you just need a fail handler:

$filePromise = PFile::open($fileName, 'w');
$filePromise.then(function($file) { ... write to file... });
$filePromise.then(function($file) { //do nothing }, function($err) { ...
log error ... });

With done/fail it's much clearer:

$filePromise = PFile::open($fileName, 'w');
$filePromise.done(function($file) { ... write to file... });
$filePromise.fail(function($err) { ... log error ... });


Bye.

[Niklas Keller]

This doesn't need an interface specification, it's just one combinator of many. Amp as a lot more combinators: http://amphp.org/docs/amp/managing-concurrency.html#combinators, I think React has a similar collection of functions.

 

Or a single interface including both static and normal methods:

interface Promise {
  public function done(callable $fn) : Promise;
  public function fail(callable $fn) : Promise;
  public function always(callable $fn) : Promise;
  public static when(Promise[] $promises) : Promise;
}

done() registers a callback to be called when the promise succeeds,
fail() does the same, but for when it fails. always() registers it to be
always called after done/fail callbacks.
when() takes an array of promises and done()s when all of them done(),
and fail()s when even a single one of them fail()s, and the callbacks
receive every promise result as parameters, in order (or an array of
them, you you want "strict typing").


What I don't like of the A+ promises is that you must provide a success
callback, even if you just need a fail handler:

$filePromise = PFile::open($fileName, 'w');
$filePromise.then(function($file) { ... write to file... });
$filePromise.then(function($file) { //do nothing }, function($err) { ...
log error ... });

With done/fail it's much clearer:

$filePromise = PFile::open($fileName, 'w');
$filePromise.done(function($file) { ... write to file... });
$filePromise.fail(function($err) { ... log error ... });

In general, using the "synchronous" approach using generator coroutines is much more preferable.

 

Bye.

[Christopher Pitt]

Gentlemen. The purpose of this thread is to establish the viability of a Promise and Event Loop PSR. I think there is enough interest, and enough interested parties that we can safely go ahead with writing a specification. A specification that we can expect will have support when it comes time for an entrance vote.

@Chris (and others in this subthread): observables look interested, though I think we need more time to consider whether now is the right time to try for a PSR for them. I do not think they conflict with an attempt to create a Promise PSR. We have a history of bring standard language to already-established patterns. There are already established implementations of promises (Guzzle, Icicle, React, Amp), so let's bring them in line with each other. Observables can (and arguably should) become a thing, but I think there's enough reason to make that a different thread to this.

@Niklas (and others in this subthread): The exact implementation of Promise (and related marshalling code) is something for the editor and coordinate to consider when it comes to making an initial draft. After that, the draft can go into entrance vote. Since the purpose of this thread is to establish a team(s) and discover interest, we can save these (interested but separate) conversations for when we have a draft to work with, and the draft has been accepted in an entrance vote.

So: we have an editor (Jeremy Lindblom) for Promise PSR, and an Editor (Andrew Carter) and Coordinator (Christopher Pitt) for Event Loop PSR. Are there any volunteers for coordinator for Promise PSR?

[Christopher Pitt]

See: https://groups.google.com/forum/#!topic/php-fig/prIQUeGYLBs

See: https://groups.google.com/forum/#!topic/php-fig/W3aw2gr1YP8

[Chris Boden]

@Alessandro: In your first example you resolve the connection asynchronously then use two blocking API's inside the resolution -- this kind of code demonstrates one of the limits of promises: you want an iteration but Promises only resolve once. Why standardize an interface of "one" -- as Larry says "One is a special case of many" which is why I'm pushing for Observables as they're built for many. 

@Christopher - I feel Promises WERE a step in the right direction from callbacks but the evolution has come around to Observables. Given their technical inferiorities I feel you're doing the community a disservice by promoting them through a body as recognized as a PSR when you could promote a better set of interfaces. Yes, several libs (including React) currently utilize Promises - but I'd like to point out Guzzle for a moment; when PSR-7 started it was based on how Guzzle did things, it evolved to immutability and copies and Guzzle updated to match that as it was a better design. I'm suggesting to take a look into Observables and do the same thing: push forward a better interface instead of settling on what devs have done in the past because everyone else jumped off a bridge. 

To counter a previous comment on resolving a promise with a generator: how do you handle errors in the iteration after initial resolution? Can you signal the end of a stream with a generator WHEN using co-operative multi tasking (I'm asking, don't know if/how here)? Also I'd like to point out I'm (99%) sure co-operative multitasking and generators can work with Observables. 

Cheers.

[Evert Pot]

On 2015-10-27 3:41 PM, Chris Boden wrote:
> @Alessandro: In your first example you resolve the connection
> asynchronously then use two blocking API's inside the resolution -- this
> kind of code demonstrates one of the limits of promises: you want an
> iteration but Promises only resolve once. Why standardize an interface
> of "one" -- as Larry says "One is a special case of many" which is why
> I'm pushing for Observables as they're built for many.
>
> @Christopher - I feel Promises WERE a step in the right direction from
> callbacks but the evolution has come around to Observables. Given their
> technical inferiorities I feel you're doing the community a disservice
> by promoting them through a body as recognized as a PSR when you could
> promote a better set of interfaces. Yes, several libs (including React)
> currently utilize Promises - but I'd like to point out Guzzle for a
> moment; when PSR-7 started it was based on how Guzzle did things, it
> evolved to immutability and copies and Guzzle updated to match that as
> it was a better design. I'm suggesting to take a look into Observables
> and do the same thing: push forward a better interface instead of
> settling on what devs have done in the past because everyone else jumped
> off a bridge.

I find Observables a lot less intuitive than Promises, for cases where a
Promise suffices, and there's a lot of cases where this is true.

I think there's a place for both paradigms.

>
> To counter a previous comment on resolving a promise with a generator:
> how do you handle errors in the iteration after initial resolution? Can
> you signal the end of a stream with a generator WHEN using co-operative
> multi tasking (I'm asking, don't know if/how here)? Also I'd like to
> point out I'm (99%) sure co-operative multitasking and generators can
> work with Observables.

You don't handle errors after the initial resolution, because a Promise
can only resolve once. Clearly this implies that a Promise is not good
enough for certain use-cases, which makes total sense.

Lets not make this an A vs B thing. I noticed even the ES6 Observable
proposal returns a Promise at one point.

Evert

[Chris Boden]

But I am making this an A vs a B thing!  :-)   There is nothing a Promise can do that an Observable can't. 

[Christopher Pitt]

But I am making this an A vs a B thing!  :-)   There is nothing a Promise can do that an Observable can't. 

 

There's nothing PHP can do that Assembly can't. There's place for both... :D

[David Dan]

Hello everyone.  This is my first time posting to this group, so go easy on me;-)

I'm one of the lead developers of Thruway and we use promises in almost everything we do.  I'm also a contributor to Rx.PHP.

One of the great things about PHP is that it's a "pirate" language.  This gives us the luxury to wait and steal the best ideas from other languages.  In this case, I think that there is a growing consensus in the JS community that Observables are better than Promises.

Here's a segment of a video from Ben Lesh that talks about some of the benefits:  https://www.youtube.com/watch?v=KOOT7BArVHQ&feature=youtu.be&t=437

From an API prospective the difference is semantics.  The core Observable is almost identical to a Promise.  The only real differences are that you use 'subscribe' instead of 'then' and that nothing happens until you subscribe.  My guess is that the "unintuitiveness" of Observables comes from the plethora of operators, which are insanely powerful, but completely optional and wouldn't belong in a PSR anyway.

Thanks,

Dave

On Thursday, October 8, 2015 at 6:19:19 PM UTC-4, Christopher Pitt wrote:

Hello fine people!

There are three popular projects implementing slightly different versions of reactive (event-based) architecture, in PHP. And probably a bucket-load of smaller stuff that goes unnoticed. 

[Christopher Pitt]

@Chris and @David: do all your functions return scalar values or objects wrapped in arrays? Sometimes we know when we will only need/return a single async value. Why only enforce an iteration approach to async value resolution? Promises and Observables compliment each other, and I really do think there is place for both...

[Niklas Keller]

David,

How will Observables work with coroutines using Generators in PHP?

Regards, Niklas

[Christopher Pitt]

@Niklas like this: https://github.com/icicleio/icicle/tree/feature/observables

[Niklas Keller]

Better link: https://github.com/icicleio/icicle/compare/feature/observables

I think that there is a growing consensus in the JS community that Observables are better than Promises.

The point I actually wanted to highlight is the following: Observables resolve to multiple values, so the foreach is perfectly fine in those examples. But promises will still be needed for single value async operations, otherwise there's no good way to have simple things like `$response = yield $httpClient->request(...)`, as long as you don't just use the first value of an observable here.

[Chris Boden]

@Christopher @Niklas: "One is a special case of many"

[Chris Boden]

https://gist.github.com/cboden/8e6f60e7cdf7304ebd40

[Christopher Pitt]

@Chris: I read and agree with that quote.

Perhaps these questions will advance the discussion:

• Does anybody here think we should not have an Observables PSR in future?
  
• Who here things we should not have a Promise PSR because of a future Observables PSR?
  
• Can we go ahead with creating a Promise PSR, given there doesn't appear to be significant opposition to it?

Obviously we (and perhaps I mean just me here) want to hear everyone's thoughts on this. It benefits nobody if we let this stall for the sake of trying to please 100% of people though... :(

Kind regards

Chris

[Jeremy Lindblom]

1. I'm currently indifferent to a future observables PSR

2. I definitely want to see a promises PSR

3. I am waiting for this discussion to have some sort of resolve before writing up a draft of the promises PSR.

--

Jeremy Lindblom (@jeremeamia)

Software Engineer at Engrade

McGraw-Hill Education

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a4a879ba-b068-470d-8646-679a111b1c70%40googlegroups.com.

[Larry Garfield]

1) +1 on an Observable PSR at some point.
2) I don't feel a Promises PSR would preclude that, and commit to (politely) slapping anyone who argues against an Observable PSR in the future on those grounds. :-)
3) At this time I would still +1 a Promises PSR vote.

PS: Chris Boden, I find it highly amusing that you're quoting me from DIG London in this thread. :-)  (Even if I don't think it entirely applies in this case.)

--Larry Garfield

[Chris Boden]

1) No

2) Me

3) -1

[Aaron Piotrowski]

I think that a Promise PSR and Observable PSR do not need to be mutually exclusive. Promises and observables are complements to each other. Promises are the asynchronous representation for a single value, while observables are the asynchronous representation of a collection (iterable). Single values can be represented as a collection containing only one item, but it rare to do so. Implementations and proposals for observables often use promises under the hood and/or have methods that return promises [1, 2].  I think that the two can and should coexist.

[1] https://github.com/zenparsing/es-observable

[2] https://github.com/icicleio/icicle/tree/feature/coroutine-observables/src/Observable

[Dracony]

I think we really need to wait until there are more libraries implmenting/using Promises/Observables before standardizing them. Then we could get more input from the people actually working with and handling those. I know of a precious few PHP projects using Promises but Observables are deifnitely currently foreign in the PHP world.

[Márk Sági-Kazár]

I think this would be a never ending loops: some libraries are waiting for a standard, so they don't implement their own until a standard is out.

Httplug is also interested in a Promise standard, as we would use it with our Async client.

[Márk Sági-Kazár]

I saw an upcoming event loop PSR mentioned in other threads. What about a Promise PSR?

[Aurimas Niekis]

And here I am writing another Promise library because there is no normal library doing everything in logic...