Op di 25 nov 2025 om 11:36 schreef Rob Landers <[email protected]>: > > > If we're going to have to recreate some of the most basic interfaces to get > async to work ... does it make sense to seriously consider coloured > functions? As annoying as it would be to refactor so much code, I think we > could realistically provide ourselves escape hatches by not requiring every > function calling `await` to be async? >
I have worked with coloured functions in PHP when Fibers were not around and the developer experience is very bad. Before PHP 8.1; every function I wrote would be coloured by either accepting or returning a Promise<sometype> (which is made worse by the fact there's no generics). Since PHP 8.1; I can use Fibers and implement a widely spread Interface in an async way. Currently, if I want to use an SDK client, the first thing that I check is `composer.json` to find out what HTTP client it uses. If it accepts a PSR-18 ClientInterface I use a small wrapper around ReactPHP's Browser that awaits a Promise and I'm set. We've been talking about shared state and possible breaks in backwards compatibility, but I must say that in reality it's not something that I find being in the way very often. Like I've made it seem before, if there's any serious breaks in backward compatibility (not the order of log lines that might be different from the sync implementation) I would at that point just document the change and release a new major version of a library. That is a lot less painful imo than working with coloured functions. Best Regards, Bart
