[PHP-DEV] Re: [PHP-CVS] com php-src: Prepare 7.3.6RC1: NEWS Zend/zend.h configure.ac main/php_version.h

2019-05-14 Thread Rasmus Lerdorf
Christoph, I think we should merge http://git.php.net/?p=php-src.git;a=commitdiff;h=5c4d125d4c2976236e2ecddd1d8c6e7b113ec482 into 7.3.6. -Rasmus

Re: [PHP-DEV] Re: [RFC] Allow throwing exceptions from __toString()

2019-05-14 Thread Dan Ackroyd
On Tue, 14 May 2019 at 17:55, Matteo Beccati wrote: > > Perhaps the section can be expanded to illustrate to non-internal people > how much work it is to upgrade the average extension or what happens if > they don't. > It will vary per extension. For some it will be none. For others it will be 's

Re: [PHP-DEV] Wiki permissions

2019-05-14 Thread Christoph M. Becker
On 14.05.2019 at 23:04, Scott Dutton wrote: > It's exussum > > > On 10 May 2019 05:26:39 BST, Scott Dutton wrote: >> >> Could I get Wiki permissions to create an RFC for >> >> https://externals.io/message/104618 You should have rfc karma now. -- Christoph M. Becker -- PHP Internals - PHP Runti

Re: [PHP-DEV] Wiki permissions

2019-05-14 Thread Scott Dutton
It's exussum Thanks Scott On 10 May 2019 05:26:39 BST, Scott Dutton wrote: >Hi > >Could I get Wiki permissions to create an RFC for > >https://externals.io/message/104618 > >Thanks > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP header files, restrict to declaring code only

2019-05-14 Thread Larry Garfield
On Mon, May 13, 2019, at 7:49 AM, Johannes Schlüter wrote: > On Fr, 2019-05-10 at 15:14 +0200, Lynn wrote: > > Hi Nikita, > > > > By limiting a header file to declaring code only, a couple of issues > > could > > be tackled: > > > > 1. No side effects when loading files. You can assume the global

Re: [PHP-DEV] Re: [RFC] Allow throwing exceptions from __toString()

2019-05-14 Thread Matteo Beccati
Hi Christoph, On 14/05/2019 16:13, Christoph M. Becker wrote: On 14.05.2019 at 15:52, Matteo Beccati wrote: How would the change affect extension developers? See . Perhaps the section can be expanded to illustrate to non-int

Re: [PHP-DEV] Add get_mangled_object_properties()

2019-05-14 Thread Nikita Popov
On Tue, May 14, 2019 at 4:37 PM Marco Pivetta wrote: > > On Tue, May 14, 2019 at 4:29 PM Benjamin Morel > wrote: > >> I like the explicitness of the proposal, but only if performance is as >> good >> as (array) cast. One of the reasons we use casting to array in libraries >> is >> not only to ac

Re: [PHP-DEV] Add get_mangled_object_properties()

2019-05-14 Thread Nikita Popov
On Tue, May 14, 2019 at 4:29 PM Benjamin Morel wrote: > I like the explicitness of the proposal, but only if performance is as > good as (array) cast. One of the reasons we use casting to array in > libraries is not only to access all properties at once, but also because > it's fast as it's imple

Re: [PHP-DEV] Add get_mangled_object_properties()

2019-05-14 Thread Marco Pivetta
On Tue, May 14, 2019 at 4:29 PM Benjamin Morel wrote: > I like the explicitness of the proposal, but only if performance is as good > as (array) cast. One of the reasons we use casting to array in libraries is > not only to access all properties at once, but also because it's fast as > it's imple

Re: [PHP-DEV] Add get_mangled_object_properties()

2019-05-14 Thread Benjamin Morel
I like the explicitness of the proposal, but only if performance is as good as (array) cast. One of the reasons we use casting to array in libraries is not only to access all properties at once, but also because it's fast as it's implemented as an opcode and not a function call. Would this function

Re: [PHP-DEV] Re: [RFC] Allow throwing exceptions from __toString()

2019-05-14 Thread Christoph M. Becker
On 14.05.2019 at 15:52, Matteo Beccati wrote: > On 14/05/2019 12:44, Nikita Popov wrote: > >> The target is 7.4 because the BC break is minimal and largely >> theoretical. >> I think the main affected code will be Symfony's existing hack around the >> issue -- they'll have to disable the hack for

Re: [PHP-DEV] Re: [RFC] Allow throwing exceptions from __toString()

2019-05-14 Thread Matteo Beccati
Hi Nikita, On 14/05/2019 12:44, Nikita Popov wrote: The target is 7.4 because the BC break is minimal and largely theoretical. I think the main affected code will be Symfony's existing hack around the issue -- they'll have to disable the hack for PHP >= 7.4 and just use the native support. How

Re: [PHP-DEV] Add get_mangled_object_properties()

2019-05-14 Thread Steven Wade
> Inspired by the recent discussion on __toArray(), I'd like to propose the > addition of a get_mangled_object_properties() function, implemented in > https://github.com/php/php-src/pull/4163. > > This function returns the mangled object properties (duh...), which matches > the behavior of the (ar

[PHP-DEV] Add get_mangled_object_properties()

2019-05-14 Thread Nikita Popov
Hi internals, Inspired by the recent discussion on __toArray(), I'd like to propose the addition of a get_mangled_object_properties() function, implemented in https://github.com/php/php-src/pull/4163. This function returns the mangled object properties (duh...), which matches the behavior of the

Re: [PHP-DEV] RE: [RFC][VOTE] Spread Operator in Array Expression v0.2

2019-05-14 Thread Nikita Popov
On Wed, May 8, 2019 at 8:15 PM CHU Zhaowei wrote: > Sorry for the one day delay. This RFC has passed with 43 votes in favor and > 1 against. > > > > Thanks & Regards, > > CHU Zhaowei > I've merged the implementation for this RFC yesterday. However, I would like to propose adding one extra restri

Re: [PHP-DEV] Re: [RFC] Allow throwing exceptions from __toString()

2019-05-14 Thread Nikita Popov
On Mon, May 13, 2019 at 5:08 PM Andreas Heigl wrote: > Hey Nikita, hey all > > Am 13.05.19 um 16:05 schrieb Nikita Popov: > > On Tue, Apr 30, 2019 at 3:32 PM Nikita Popov > wrote: > > > >> Hi internals, > >> > >> I've already brought up this topic on list a couple of weeks ago... I've > >> now u

Re: [PHP-DEV] Re: Proposal for a RFC

2019-05-14 Thread Rowan Collins
On Mon, 13 May 2019 at 19:55, Steven Wade wrote: > I'm personally unconvinced of the value of this, and would probably propose > it was blocked by coding standards in my team if it was added, because its > meaning is so ambiguous. > > > That's perfectly reasonable. Do you also block use of castin