Re: PHP True Async RFC Stage 3
Hello, everyone.
While the code is being developed and changes for the RFC are in
progress, I’d like to share a real-world situation.
This is one of those cases that once again proves why software design
cannot happen without writing real code — why architecture is
impossible without practice.
```php
function any(iterable $triggers): Awaitable {}
function all(iterable $triggers): Awaitable {}
function anyOf(int $count, iterable $triggers): Awaitable {}
function captureErrors(Awaitable $awaitable): Awaitable {}
```
In the latest version of the **RFC**, I tried to split the awaitAll
function into a separate all() function, so it could be combined
with await. This solution seemed very elegant to me, as it aligns with
the principle of separation of concerns in design.
What could go wrong?
As I began implementing the concurrent iterator (i.e., refactoring the
old code using the new approaches), it became clear that the Awaitable
object returned by functions must be able to be awaited multiple
times. But that means the iterator may need to maintain complex
internal state to correctly pause and resume execution. I became
curious about how many edge cases could arise in this situation and...
it terrified me.
So much for “elegant design.” All that glitters is not gold..
It might be possible to find a golden mean between implementation and
interface elegance.
Have a good day.
-- Ed
Thread (12 messages)