Hi Hammed, thank you for taking the time to read through this and share your
thoughts.
> On Sep 19, 2024, at 1:41 PM, Hammed Ajao wrote:
>
>
>
>
> On Tue, Sep 17, 2024 at 8:30 PM Dennis Snell > wrote:
>
>>
>>
>>
>>> On Sep 17, 2024, at 2:03 PM, Rob Landers wrote:
>>>
>>>
>>>
>>>
>>
> On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP]
> wrote:
>
> On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote:
>> Yeah. That was the original goal.
>>
>> But to say WASM's domain is limited to browsers is not valid any longer:
>> [...]
>
> While it's definitely interesting seeing what
On Tue, Sep 17, 2024 at 8:30 PM Dennis Snell
wrote:
>
> On Sep 17, 2024, at 2:03 PM, Rob Landers wrote:
>
>
>
> On Tue, Sep 17, 2024, at 14:57, Adam Zielinski wrote:
>
> > To summarize, I think PHP would benefit from:
> >
> > 1. Adding WASM for simple low-level extensibility that could run on
>
On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel wrote:
> > On Sep 18, 2024, at 3:09 PM, Hammed Ajao wrote:
> > Yes and no. The primary goal of WebAssembly is to support
> high-performance applications on web pages. The premise is simple:
> JavaScript is the only language natively supported by brow
On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote:
> Yeah. That was the original goal.
>
> But to say WASM's domain is limited to browsers is not valid any longer:
> [...]
While it's definitely interesting seeing what uses it's being put to beyond the
browser, the majority of those articles are
Hi
Am 2024-09-02 15:24, schrieb Christoph M. Becker:
Now, comparing strstr() and strrchr() is of course still possible, but
different behavior is less astonishing. Of course, strrchr() could
warn
or even throw if $needle has more than one character, but that may
unnecessarily break code for a
Hi
Am 2024-09-05 18:03, schrieb John Coggeshall:
I would suggest we take a step back from this and look at it with a bit
more of a wider lens. It seems to me that this would be a good place to
have an attribute (e.g. #[NotSerializable] ) that could be defined for
any class (with ZEND_ACC_NOT_S
I've voted to deprecate based on my understanding that either passing
a non-empty string or relying on the default value would trigger a
deprecation. It wouldn't make sense for me to only deprecate passing
an explicit argument.
I agree that the path forward has not been made clear in the RFC. Will
Hi all,
there is some debate regarding the implementation of the "Deprecate
proprietary CSV escaping mechanism" RFC section[1], which needs
clarification from the list, in my opinion.
That RFC section perhaps used some unclear wording:
| Which is to deprecate passing a non-empty string to the $e
