On March 1, 2019 10:52:02 PM GMT+01:00, "Christoph M. Becker"
wrote:
>On 01.03.2019 at 21:31, Johannes Schlüter wrote:
>
>> On Fr, 2019-03-01 at 18:28 +0100, Nikita Popov wrote:
>>> made the same mistake there. So there's one more point to add to the
>>> extension guidelines:
>>
>> Do we have
On 01.03.2019 at 21:31, Johannes Schlüter wrote:
> On Fr, 2019-03-01 at 18:28 +0100, Nikita Popov wrote:
>> made the same mistake there. So there's one more point to add to the
>> extension guidelines:
>
> Do we have a persistent space to keep those? The internals manual is
> limited ... :-)
And
On Fr, 2019-03-01 at 18:28 +0100, Nikita Popov wrote:
> made the same mistake there. So there's one more point to add to the
> extension guidelines:
Do we have a persistent space to keep those? The internals manual is
limited ... :-)
> I'm happy to find and fix these bugs, rather than leave the l
On Fri, Mar 1, 2019 at 5:24 PM Johannes Schlüter
wrote:
> On Fr, 2019-03-01 at 12:25 +0100, Nikita Popov wrote:
>
> > For extension authors, the guideline is:
>
> Will zend_parse_paramters and related detect if an exception is thrown
> and fail?
>
Yes, of course :) That's one of the most importa
On Fr, 2019-03-01 at 12:25 +0100, Nikita Popov wrote:
> For extension authors, the guideline is:
Will zend_parse_paramters and related detect if an exception is thrown
and fail?
I believe things like database (or other network) extensions have to be
really carefully checked, not that we store co
Hi internals,
I have opened voting on https://wiki.php.net/rfc/custom_object_serialization.
The vote will be open until 2019-03-15.
You can find the discussion thread for this proposal here:
https://externals.io/message/103823
Regards,
Nikita
branch are available here
https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190301/
Regards
Anatol
> On 2/22/19 3:21 PM, Joe Watkins wrote:
> > Thanks for all the effort Dmitry, it's looking in much better shape.
> >
> > Cheers
> > Joe
> >
> >
Am 17.02.2019 um 17:24 schrieb Nikita Popov :
> The recommended upgrade path here is basically "deal with it". If a
> codebase does this (intentionally calling functions with invalid params and
> suppressing errors) a lot, then it might make sense to register an error
> handler that collects all
Hi internals,
We currently forbid throwing exceptions from __toString() and instead
convert them into fatal errors. The rationale for this behavior is that
string conversions are performed in many places throughout the engine and
standard library, and not all places performing these conversions wi
