Hello Aaron,
First, I want to say that I love this proposal and would love to see it land in
the next PHP release, but I have one question regarding this:
> Promises result in the “What color is your function” problem as described in
> the introduction of the RFC. Returning promises from functions means that
> functions calling those functions must also return promises, resulting in the
> entire call stack needing to return promises.
Hack-Lang provides `HH\Asio\join` function which allows awaiting Awaitables in
sync code, so you are capable of running multiple async tasks concurrently
without having to declare the entire call stack as "async" or with an
"Awaitable" return type, isn't this possible?
```
use namespace HH\Asio;
async function async_task(): Awaitable<void> {
await Asio\usleep(1000000);
}
<<__EntryPoint>>
function main(): void {
$start = microtime(true);
$async = async {
concurrent {
await async_task();
await async_task();
};
return 'hello';
};
$result = Asio\join($async);
printf('Result: %s ( %f )', $result, microtime(true) - $start); // output
"Result: hello ( 1.010382 )"
}
```
Regards,
Saif.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, December 17, 2020 8:43 PM, Aaron Piotrowski <aa...@trowski.com>
wrote:
> Hi Peter,
>
> > On Dec 17, 2020, at 1:23 PM, Peter Stalman sarke...@gmail.com wrote:
> > Hi Aaron, this is very interesting to me. Can I ask why this approach as
> > opposed to other paradigms like promises, coroutines, etc? You mentioned
> > async/await in the future scope, and I assume most of these patterns can be
> > implemented once there is an underlying functionality. Basically, why
> > fibers instead of x?
>
> Promises result in the “What color is your function” problem as described in
> the introduction of the RFC. Returning promises from functions means that
> functions calling those functions must also return promises, resulting in the
> entire call stack needing to return promises.
>
> Fibers are a method of implementing coroutines or interruptible functions.
> Promises likely would still be used as placeholders in libraries using
> fibers, but coroutines written using fibers do not have to return another
> placeholder. Fibers allow async code to be indistinguishable from sync code,
> as opposed to an approach where async functions must return a promise.
>
> > You also mentioned this isn't really intended to be used directly, but with
> > a library such as AMPHP. IS the expectation that non-blocking I/O
> > functionality like database drivers and file operation be provided by
> > libraries as well?
>
> Since most code written for PHP is blocking, yes, such libraries/frameworks
> would need to provide functionality such as database drivers. Both AMPHP and
> ReactPHP already have existing async drivers available for several different
> popular database systems. AMPHP’s postgres, mysql, and redis drivers already
> have a version using fibers.
>
> > I hope I don't come off as critical, I am merely curious. Thank you for
> > pushing this forward, as async is something PHP has been lacking and should
> > have IMO to compare favourably to other alternatives that do.
>
> You didn’t com off as critical at all! These were good questions to ask. I
> too think if PHP is to add support for async code it should compare favorably
> to other languages. I think fibers offer a distinct advantage to using
> promise for async code.
>
> Cheers,
> Aaron Piotrowski
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
