Re: [PHP-DEV] PHP True Async RFC

> > Neither of these is a bad use case, and they're not mutually exclusive, but they do lead to different priorities. > I freely admit my bias is towards Type 1, while it sounds like Edmond is coming from a Type 2 perspective. > Exactly. A coroutine-based server is what I work with, so this aspect

Re: [PHP-DEV] PHP True Async RFC

On 8 March 2025 21:42:21 GMT, Daniil Gentili wrote: > >To make an analogy, it's like saying PHP should have an io {} block, that >makes sure all file resources opened within (even internally, 10 stack levels >deep into 3 libraries, whose instances are all used after the io {} block) are >clo

Re: [PHP-DEV] PHP True Async RFC

Hi, To see to be posting a reply to nearly every other email on this thread. I'd recommend you have another read through our mailing list rules: cheers Derick On 8 March 2025 22:28:58 GMT, Daniil Gentili wrote: >>> To m

Re: [PHP-DEV] PHP True Async RFC

Hi Edmond, On Sat, Mar 8, 2025, 19:18 Edmond Dantes wrote: > This situation is solely due to the fact that the Scheduler contradicts of > Fiber. > >- The Scheduler expects to switch contexts as it sees fit. >- Fiber expects context switching to occur only between the >Fiber-parent an

Re: [PHP-DEV] Re: PHP True Async RFC

On Sat, Mar 8, 2025, at 1:05 AM, Edmond Dantes wrote: > Hello all. > > A few thoughts aloud about the emerging picture. > > ### Entry point into the asynchronous context > Most likely, it should be implemented as a separate function (I haven't > come up with a good name yet), with a unique name to

Re: [PHP-DEV] PHP True Async RFC

> > Crippling async PHP with async blocks just because some libraries aren't ready for concurrency now, means crippling the future of async php. > How can calling a single function have such a destructive impact on the future of PHP? Yes, you have to write 10-20 more characters than usual one tim

Re: [PHP-DEV] PHP True Async RFC

>>> The async block as I'm picturing it has nothing to do with function >>> colouring, it's about the outermost function in an async stack being able >>> to say "make sure the scheduler is started" and "block here until all child >>> fibers are either concluded, detached, or cancelled". >> >> T

Re: [PHP-DEV] PHP True Async RFC

>>  Crippling async PHP with async blocks just because some libraries aren't >>ready for concurrency now, means crippling the future of async php. >> > How can calling a single function have such a destructive impact on the > future of PHP?  Very simple: to make an analogy, it's like saying PH

Re: [PHP-DEV] PHP True Async RFC

>> To make an analogy, it's like saying PHP should have an io {} block, that >> makes sure all file resources opened within (even internally, 10 stack >> levels deep into 3 libraries, whose instances are all used after the io {} >> block) are closed when exiting. > > Traditional PHP offers exact

Re: [PHP-DEV] PHP True Async RFC

> Offering this tool to userland is a major footgun that will either backfire > spectacularly (breaking existing and new async libraries by endlessly > awaiting upon background fibers when exiting an async {} block haphazardly > used by a newbie, or even worse force library developers to reduce

Re: [PHP-DEV] PHP True Async RFC

On 8 March 2025 13:38:30 GMT, Daniil Gentili wrote: > >> The async block as I'm picturing it has nothing to do with function >> colouring, it's about the outermost function in an async stack being able to >> say "make sure the scheduler is started" and "block here until all child >> fibers a

Re: [PHP-DEV][RFC][VOTE] Add mb_levenshtein function

On 08/03/2025 03:30, youkidearitai wrote: > Hi, Internals > > The add mb_levenshtein was end and declined. > Vote result is one yes and 5 no. > > Thank you very much voting. > > By the way, This message is means add grapheme_levenshtein instead of > mb_levenshtein? > Or nothing to do? > Feel fr

Re: [PHP-DEV] PHP True Async RFC

> > Colored functions completely preclude a possible future thread-based implementation of concurrency. > I can assure you that colored functions are neither part of this RFC nor *any future ones* from me. And it's not because it's my decision it's rather the language itself and the existing code

Re: [PHP-DEV] PHP True Async RFC

I will just put this picture here On Sat, Mar 8, 2025 at 2:27 PM Edmond Dantes wrote: > > > > Colored functions completely preclude a possible future thread-based > implementation of concurrency. > > > > I can assure you that colored functions are neither part of this RFC nor *any > future ones

Re: [PHP-DEV] PHP True Async RFC

On Sat, Mar 8, 2025, at 8:00 AM, Daniil Gentili wrote: >> As far as I can tell, the entire reason we are talking about this is because >> adding the event loop changes the behavior of existing code. So we cannot >> "just turn it on". >> >> I haven't seen an explanation of why this is the case,

Re: [PHP-DEV] PHP True Async RFC

> > This also seems like a very bad idea: there is no reason for the language hide concurrency behind an INI or even worse a compilation flag. > This is not because someone wants it that way. This situation is solely due to the fact that the Scheduler contradicts of Fiber. - The Scheduler exp

Re: [PHP-DEV] PHP True Async RFC

> In my opinion, colored functions is the worst thing that could happen to PHP. > > https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function > Describes quite expressively what's wrong about this approach. > > This is going to be a ton of changes, when currently sync (blue functio

Re: [PHP-DEV] PHP True Async RFC

> In my opinion, colored functions is the worst thing that could happen to PHP. > > https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function > Describes quite expressively what's wrong about this approach. > > This is going to be a ton of changes, when currently sync (blue function

Re: [PHP-DEV] Re: PHP True Async RFC

> > This is incorrect. "Create an async bounded context playpen" (what I called "async" in my example) > and "start a fiber/thread/task" (what I called "spawn") are two *separate* operations, and > must remain so. > > So, you use *async* to denote the context and *spawn* to create a coroutine. Re

Re: [PHP-DEV] PHP True Async RFC

> > Yes, that is much much nicer! It feel familiar to go: > > go file_get_contents($file[$i]) > > And yes, I realize that would be a fun error in go, but you get the gist. > > — Rob > Yes, that's the point that we don't bother client code with any of the async stuff 🙂 If we want to create "async

Re: [PHP-DEV] PHP True Async RFC

> >for($i = 0; $i < 10; $i++) $results[] = async\async(fn($f) => file_get_contents($f), > $file[$i]); > // convert $results into futures somehow -- though actually doesn't look like it is > possible. > $results = async\awaitAll($results); > Future can be obtained via getFuture(), according to the

Re: [PHP-DEV] PHP True Async RFC

> > Let's assume we want to support this scenario; we could: > Thank you, that's an accurate summary. I would focus on two options: 1. Creating child coroutines by default, but allowing unbound ones to exist. 2. Explicitly creating child coroutines. And in the RFC, I would leave the ch

Re: [PHP-DEV] PHP True Async RFC

On Sat, Mar 8, 2025, at 09:24, Edmond Dantes wrote: > > > >for($i = 0; $i < 10; $i++) $results[] = async\async(fn($f) => > >file_get_contents($f), > > $file[$i]); > > // convert $results into futures somehow -- though actually doesn't look > > like it is > > possible. > > $results = async\awai

Re: [PHP-DEV] PHP True Async RFC

On Sat, Mar 8, 2025, at 14:38, Daniil Gentili wrote: > > > The async block as I'm picturing it has nothing to do with function > > colouring, it's about the outermost function in an async stack being able > > to say "make sure the scheduler is started" and "block here until all child > > fibers

Re: [PHP-DEV] PHP True Async RFC

> The async block as I'm picturing it has nothing to do with function > colouring, it's about the outermost function in an async stack being able to > say "make sure the scheduler is started" and "block here until all child > fibers are either concluded, detached, or cancelled". There's no nee

Re: [PHP-DEV] PHP True Async RFC

> As far as I can tell, the entire reason we are talking about this is because > adding the event loop changes the behavior of existing code. So we cannot > "just turn it on". > > I haven't seen an explanation of why this is the case, but that's how we got > to this point. We need some way to "

Re: [PHP-DEV] PHP True Async RFC

> Again, take a look at how nicely golang handles concurrency with colorless > functions: php fibers weren't the first to do it. Also, a colored functions approach for php would make a future thread-based concurrency approach completely non-viable, because it would require marking ALL function

Re: [PHP-DEV] PHP True Async RFC

> you //never// get to decide unless you wrap it in a specific form (async\run > or async\async, in this RFC), which ironically colors the function. You're wrong, it does *not* color the function: spawning a new fiber does not make the code running it async: it is always async, regardless of whe

Re: [PHP-DEV] PHP True Async RFC

Mar 8, 2025 9:29:15 AM Edmond Dantes : >>  >>for($i = 0; $i < 10; $i++) $results[] = async\async(fn($f) => >>file_get_contents($f), >> $file[$i]); >> // convert $results into futures somehow -- though actually doesn't look >> like it is >> possible. >> $results = async\awaitAll($results); >> > >

Re: [PHP-DEV] PHP True Async RFC

One person observes 3 persons and he is curious what they are doing because it looks strange. The first person digs a hole. The second person buries the hole. The third person waters the buried hole. He asks them: Why are you doing this? They say: There is a fourth person that plants the seeds but

Re: [PHP-DEV] PHP True Async RFC

>> As far as I can tell, the entire reason we are talking about this is because >> adding the event loop changes the behavior of existing code. So we cannot >> "just turn it on". >> >> I haven't seen an explanation of why this is the case, but that's how we got >> to this point. We need some wa

Re: [PHP-DEV] PHP True Async RFC

> > > The uncoloring of functions in PHP is probably one of the most annoying > aspects of fibers, IMHO. It's hard to explain unless you've been using them > awhile. But, with colored functions, the caller has control over when the > result is waiting on -- it could be now, it could be in a totally

Re: [PHP-DEV] PHP True Async RFC

> > wrap it in a specific form (async\run or async\async, in this RFC), which > ironically colors the function. > It doesn't color the function. The function is unchanged. Any existing function in userland do not have to be changed in any way. It's calls do not have to be rewritten into await, an

Re: [PHP-DEV] PHP True Async RFC

On 8 March 2025 10:44:35 GMT, Daniil Gentili wrote: >The only thing that's truly needed in this RFC is a set of synchronization >primitives like in golang, and a way to parent/unparent fibers in order to >inherit cancellations (as previously mentioned in this list), not contexts, >async blo

Re: [PHP-DEV] PHP True Async RFC

I don't want to get involved, I'm giving just an opinion. If my wife wants me to get a present for someone and she wants me to get it wrapped up in either "green with orange ribbon" or "blue with red ribbon" (strictly) but I have to buy them separately from a different shops. If I buy orange ribbon

Re: [PHP-DEV] RFC: short and inner classes

On Thu, Mar 6, 2025, at 02:08, Juris Evertovskis wrote: > Hi, > > Maybe I didn’t read the RFC carefully enough, but… Do any of these features > require the other one? > > I’m asking because I wouldn’t want to see them both denied just because the > voters disagree with one of them. > > Go