Hello, Vincent.
>
> Personally, i love the formal RFC for it's low level accessibility and
this new RFC isn't that bad.
>
If you mean classes like SocketHandle and so on, then the low-level API can
be available as a separate extension.
>
> The `spawn` keyword maybe the right keyword to use but
On Mon, Mar 10, 2025 at 12:07 PM Daniel Scherzer <
daniel.e.scher...@gmail.com> wrote:
> Hi internals,
>
> I'd like to start discussion on a new RFC about allowing `never` for
> parameter types when declaring a method.
>
> * RFC: https://wiki.php.net/rfc/never-parameters-v2
> * Implementation: htt
On 16/03/2025 09:24, Edmond Dantes wrote:
Good day, everyone. I hope you're doing well.
https://wiki.php.net/rfc/true_async
Here is a new version of the RFC dedicated to asynchrony.
I would like to once again thank everyone who participated in the
previous discussion. It was great!
Thank
Claude, exactly! By using '::' you cannot distinguish between a class and a
function. So this is not an option because it leads to a headache. Just my
2 cents
On Sun, Mar 16, 2025 at 11:08 PM Claude Pache
wrote:
>
>
> Le 15 mars 2025 à 12:53, Rowan Tommins [IMSoP] a
> écrit :
>
>
>
> On 14 Marc
Edmond, I program microcontrollers. I have a "main loop" and
"interruption loops" which are not part of the "main loop" since they are
dependent on some event like a button push (for example) and they are
dependent on random user input. So for the wording I would use the word
'aside' because it is
> What is this?
I mean structured concurrency:
https://wiki.php.net/rfc/true_async#structured_concurrency
What is this?
On Sun, Mar 16, 2025 at 9:30 PM Edmond Dantes wrote:
> > Spawning a child thread means you don't care about if it will ever
> finish.
>
> In the context of this RFC, the parent limits the execution time of child
> coroutines. Does this mean that the verb *spawn* is not the best ch
> Spawning a child thread means you don't care about if it will ever
finish.
In the context of this RFC, the parent limits the execution time of child
coroutines. Does this mean that the verb *spawn* is not the best choice?
Edmond, async stuff is like having another thread. So "spawn" fits but also
"throw" in terms of what it does. At least what it actually does (at least
what it must) at a low level.
> The `spawn` keyword maybe the right keyword to use but it seems more
weird, can we find another keyword to use oth
Just in case, I'll state this explicitly.
The current RFC does not remove features from the previous version; rather,
it represents its high-level part, with structural concurrency added. It
has been reduced in size, making it easier to discuss.
>From an implementation perspective, it seems that a
Personally, i love the formal RFC for it's low level accessibility and this
new RFC isn't that bad.
The `spawn` keyword maybe the right keyword to use but it seems more weird,
can we find another keyword to use other than that? Most languages i've
seen make use of only the `async/await` keyword.
Hello.
>
> Just one quick question for now; why is `suspend()` a function and not a
statement?
>
Yes, suspend() is a function from the Async namespace.
I couldn't find any strong reasons to define it as an operator:
```php
suspend();
// vs
suspend;
```
For example, the spawn operator makes the c
On 16/03/2025 09:24, Edmond Dantes wrote:
Good day, everyone. I hope you're doing well.
https://wiki.php.net/rfc/true_async
Here is a new version of the RFC dedicated to asynchrony.
Key differences from the previous version:
* The RFC is not based on Fiber; it introduces a separate class
rep
Good day, everyone. I hope you're doing well.
https://wiki.php.net/rfc/true_async
Here is a new version of the RFC dedicated to asynchrony.
Key differences from the previous version:
* The RFC is not based on Fiber; it introduces a separate class
representation for the asynchronous context.
* A
On Sat, Mar 15, 2025, 11:25 Juris Evertovskis wrote:
> The key point, hoewever, seems to be that the naming of the feature is
> excremental and very easy to misunderstand. I suppose the naming issue can
> be solved separately (if a better name is found) and the documentation can
> use a different
15 matches
Mail list logo
