Hey David,
On Fri, Feb 12, 2021, 20:24 David Rodrigues wrote:
> Hello!
>
> It is just a suggestion to be discussed.
>
> A lot of places on my projects I have codes like:
>
> $companies = $user->companies->count()
> ? new Collection($user->companies)
> : null;
>
Even upfront, this looks
> On Feb 12, 2021, at 4:05 PM, Aaron Piotrowski wrote:
>
> The Fiber API would conflict or prevent async / await from being added to PHP
> in the future. The two APIs can coexist and serve different purposes.
>
While probably obvious from the rest of the context of the email, for clarity,
I
> On Feb 12, 2021, at 3:47 PM, Mark Randall wrote:
>
> On 12/02/2021 21:40, Aaron Piotrowski wrote:
>> I would like to open voting for this RFC around the beginning of March, so
>> please review the minimal API and provide any feedback soon.
>
> Removing the scheduler was likely a good plan,
On 12/02/2021 21:40, Aaron Piotrowski wrote:
I would like to open voting for this RFC around the beginning of March, so
please review the minimal API and provide any feedback soon.
Removing the scheduler was likely a good plan, but pretty please
reconsider your future scope.
It's going to b
> On Dec 17, 2020, at 10:30 AM, Aaron Piotrowski wrote:
>
> Hello everyone!
>
> I would like to introduce an RFC for adding full-stack fibers to PHP:
> https://wiki.php.net/rfc/fibers
>
> Fibers are primarily used to implement green-threads or coroutines for
> asynchronous I/O. Fibers are s
> The => is just a suggestion, other options using existing keywords is:
> return expr() then output();
> return expr(): output();
>
> I do not know if other languages support something like that.
I think it might be a good idea to check other languages to see if they support
something like thi
Hello!
It is just a suggestion to be discussed.
A lot of places on my projects I have codes like:
$companies = $user->companies->count()
? new Collection($user->companies)
: null;
So $companies will be null except if the user has companies.
My suggestion is create some kind of inline c
Hi Alex,
> > I've created a new RFC https://wiki.php.net/rfc/cachediterable adding
> > CachedIterable,
> > which eagerly evaluates any iterable and contains an immutable copy of the
> > keys and values of the iterable it was constructed from
> >
> >
> > Any other feedback unrelated to namespaces
On 12 Feb 2021, at 15:17, Christian Schneider wrote:
>
> Am 12.02.2021 um 15:30 schrieb Craig Francis :
>> Switching the default from `OFF` to `ERROR` to `ERROR | STRICT` isn't an
>> obvious step, as that still means you're still having a single step to
>> change from error reporting to excepti
On Thu, Feb 11, 2021 at 5:47 AM tyson andre
wrote:
> Hi internals,
>
> I've created a new RFC https://wiki.php.net/rfc/cachediterable adding
> CachedIterable,
> which eagerly evaluates any iterable and contains an immutable copy of the
> keys and values of the iterable it was constructed from
>
>
Am 12.02.2021 um 15:30 schrieb Craig Francis :
> Switching the default from `OFF` to `ERROR` to `ERROR | STRICT` isn't an
> obvious step, as that still means you're still having a single step to change
> from error reporting to exceptions.
It is the usual step for (almost) all BC breaking change
On 12 Feb 2021, at 08:45, Peter Bowyer wrote:
> On Thu, 11 Feb 2021 at 13:31, Christian Schneider
> wrote:
>
>> [...] If there would have been an intermediate PHP version with default
>> MYSQLI_REPORT_ERROR I would have voted "Yes", but in the current form I
>> have to say "No".
>>
>
> I vote
On Thu, 11 Feb 2021 at 13:31, Christian Schneider
wrote:
> For the record: I do not think the wording fo the "Backward Incompatible
> Changes" section is appropriate, especially the *only* in "To bring back
> the old behaviour one needs to add only this line before instantiating
> mysqli class".
13 matches
Mail list logo
