On 20/03/2025 11:01, Edmond Dantes wrote:
> >
> > Specifically, what is the use case where syntax #2, "spawn
function_call" is not good enough, leading us to add a special case into
the grammar.
> >
> Additional parentheses around + parentheses after. That is,
(closure)(). The goal is to get r
On Sun, Mar 16, 2025 at 12:31 PM Matt Fonda wrote:
> Hi Daniel,
>
> I believe this feature essentially amounts to "add methods which can never
> be called", which in my mind makes no sense. If a method types against an
> interface, and that interface uses a method with a never parameter type,
> t
On Thu, Mar 20, 2025, at 2:06 AM, Edmond Dantes wrote:
> This is simply a wonderful explanation. I will be able to go through each
> point.
>
> But before that, let's recall what spawn essentially is.
> Spawn is an operation that creates a separate execution context and
> then calls a function
>
> Nitpick to make sure we're talking about the same thing: What does
"Separate execution context" mean here? Because a keyword whose
description includes "and" is always a yellow flag at least.
>
At the language abstraction level, we can say that spawn performs a single
operation: it creates a
>>
>> This example highlights one of the concerns I have with fibers and this
approach in general. That example will still execute synchronously, taking
file_get_contents() * 3, even though it is in a coroutine function.
>>
>Is that really a problem? If a programmer wrote the code `$x = 1 / 0`,
t
On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
>
>> Am 20.03.2025 um 15:51 schrieb Rob Landers :
>>
>>
>>
>> On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
>>>
>>>
>>> On 19.3.2025 16:04:06, Rob Landers wrote:
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
> Okay, I se
On 20 March 2025 07:06:16 GMT, Edmond Dantes wrote:
I forgot to include some relevant text to quote, but I absolutely agree that
syntax #2 should be our default.
I think the only thing I'm still unsure of is whether we need anything else on
top of it, and if so what.
>
>> 4: keyword in
```php
await $some with 5s;
```
Maybe
```php
await $some limit 5s;
```
On Thu, Mar 20, 2025 at 9:33 AM Edmond Dantes wrote:
> Hello everyone,
> I’d like to ask for your help regarding the syntax.
>
> **Goal:** I want to get rid of the `BoundedScope` object while still
> providing a convenient
This is simply a wonderful explanation. I will be able to go through each
point.
But before that, let's recall what spawn essentially is.
Spawn is an operation that creates a separate execution context and then
calls a function within it.
To perform this, spawn requires two things:
1. **callable**
Hello everyone,
I’d like to ask for your help regarding the syntax.
**Goal:** I want to get rid of the `BoundedScope` object while still
providing a convenient built-in tool for controlling wait time.
To achieve this, we could extend the `await` expression so that it allows
explicitly specifying
>
> await $some limit 5s;
>
Yes, limit is also a good keyword.
And some else examples with "until":
**CancellationExp**:
- A variable of the `Awaitable` interface
```php
$cancellation = new Future();
$result = await $coroutine until $cancellation;
```
- A function that returns an Awai
> In terms of the grammar, it is a special case of #1
yes.
> This example maybe helps explain why this might be surprising:
> spawn $action;
Aha, so if I can write `spawn closure`, why can't I do the same with a
variable?
Yes, this creates an inconsistency.
that's to be expected since the parent
On Thu, Mar 20, 2025, at 12:01, Edmond Dantes wrote:
> ```php
> spawn fn() => [file_get_content(), file_get_content(), file_get_content()]
> ```
This example highlights one of the concerns I have with fibers and this
approach in general. That example will still execute synchronously, taking
fi
On Thu, Mar 20, 2025, at 16:41, Bob Weinand wrote:
>
>> Am 20.03.2025 um 16:28 schrieb Rob Landers :
>>
>>
>>
>> On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
>>>
Am 20.03.2025 um 15:51 schrieb Rob Landers :
On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote
On Tuesday, 11 March 2025 at 21:45, Larry Garfield
wrote:
> On Mon, Mar 10, 2025, at 2:05 PM, Daniel Scherzer 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.ne
On Thu, Mar 20, 2025, at 11:09 AM, Gina P. Banyard wrote:
> Frankly, the comment from u\phuncky [1] mentioning the possibility of
> bad interactions with default interface methods (something I think is
> more important than this) is reinforcing my opinion that this RFC solve
> the problem in a
>
> This example highlights one of the concerns I have with fibers and this
approach in general. That example will still execute synchronously, taking
file_get_contents() * 3, even though it is in a coroutine function.
>
Is that really a problem? If a programmer wrote the code `$x = 1 / 0`, then
On Tuesday, 11 March 2025 at 21:17, Rowan Tommins [IMSoP]
wrote:
> On 11/03/2025 11:54, Gina P. Banyard wrote:
>
> > It also means that we need to do multiple passes, on the same code path,
> > resulting in somewhat of a code churn and possibly not using a common
> > abstraction.
> > Consideri
18 matches
Mail list logo
