"Christoph M. Becker" in php.internals (Thu, 28 Jun 2018 12:56:43
+0200):
>Apparently, zval_ptr_dtor() had to be replaced with
>zval_internal_dtor() to avoid a segfault with PHP 7.3. Is this caused
>by a change in the engine? If so, is this change documented?
Another one: some extensioms suffer
2018-07-04 0:23 GMT+02:00 Christoph M. Becker :
>
> Yeah, I'd prefer that. It's not that 2018-07-17 12:00 UTC *couldn't*
> work – it's just I'd rather have some buffer time (I presume there will
> be more RFCs whose voting ends close to feature freeze).
Alright, updated!
RFC voting now closes on
On 04.07.2018 at 00:11, Michael Moravec wrote:
> I wanted to keep it within the standard 14 days long period
> both for discussion and voting.
> If there are no objections (no votes yet), we can shorten it
> i.e. to 2018-.07-16 23:00 UTC - would that work for you?
Yeah, I'd prefer that. It's not
Hi Christoph,
I wanted to keep it within the standard 14 days long period
both for discussion and voting.
If there are no objections (no votes yet), we can shorten it
i.e. to 2018-.07-16 23:00 UTC - would that work for you?
Thanks!
M.
2018-07-03 23:52 GMT+02:00 Christoph M. Becker :
> On 03.07
On 03.07.2018 at 22:48, Michael Moravec wrote:
> Hello internals,
>
> The RFC for adding iterable_to_array() and iterable_count() is now open for
> voting:
>
> https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
Thanks for the RFC, Michael!
> You can vote for each function separately
Hello internals,
The RFC for adding iterable_to_array() and iterable_count() is now open for
voting:
https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
You can vote for each function separately.
Voting will close on 2018-07-17 12:00 UTC.
Thank you,
M.
Hi!
> In other words, $a == $b must not work if $a->__equals and $b->__equals are
> two different functions
>
> So effectively it means we only call __equals if both sides are instances
> of the same class?
We can just define that == calls __equals on the left. That's, for
example, what Python d
Hi!
> IMO, we should go the other way. Deprecate excess args in userspace
> functions (making them an error in 8.0). We've had formal variadics
> in userspace for a long time (5.5 IIRC), this is a solvable problem.
I think it's premature. We do have variadics, since 5.6
(https://github.com/php/
Hi!
> I think if you want to push the RFC forward, a really quite strong
> case needs to be made for why having it be a language level feature is
> so much better (or even at all better) than having it be implemented
> in userland.
I tend to agree here. There are not that many cases where < and >
On Tue, Jul 3, 2018 at 5:11 AM, Nikita Popov wrote:
> I'd go for master only as it's technically BC breaking.
>
Ditto this.
> Some people have plans to get rid of the warning/error on too many
> arguments to internal functions to make them consistent with user
> functions, so maybe this will beco
On Mon, Jul 2, 2018 at 11:45 PM, Christoph M. Becker
wrote:
> On 02.07.2018 at 23:16, Nikita Popov wrote:
>
> > On Mon, Jul 2, 2018 at 11:00 PM, Christoph M. Becker
> > wrote:
> >
> >> Is there any particular reason why internal functions raise a warning/an
> >> error regarding excess arguments,
11 matches
Mail list logo
