Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Paul Jones
> On Dec 12, 2016, at 13:36, Andrea Faulds wrote: > > Consider that some popular applications of immutability ultimately contain a > reference to something mutable: PSR-7's immutable HTTP message objects point > to mutable streams Which subverts its overall promise of

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Andrea Faulds
Hi Silvio, Silvio Marijić wrote: Discussion is open for following rfc https://wiki.php.net/rfc/immutability The restriction that immutable properties may only hold immutable values seems potentially overzealous. Consider that not all immutable classes will actually be marked as such. Any

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Rowan Collins
On 12 December 2016 14:42:11 GMT+00:00, "Silvio Marijić" wrote: >I understand that, but I think we'll have to meet in the middle. How >would >you handle situation where for one little change you have to manually >recreate not so trivial object with a lot of arguments ?

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Fleshgrinder
On 12/12/2016 8:19 PM, Silvio Marijić wrote: > @Fleshgrinder > > My opinion on that subject is still that features are mostly complete but > I'am willing to find also solution to ease modifying. > Modify function does not modify object in any way, it will operate on the > clone of the object and

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Silvio Marijić
@Fleshgrinder My opinion on that subject is still that features are mostly complete but I'am willing to find also solution to ease modifying. Modify function does not modify object in any way, it will operate on the clone of the object and this was just prototype. Moreover it should be restricted

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Fleshgrinder
On 12/11/2016 5:57 PM, Silvio Marijić wrote: > Hi, > > Discussion is open for following rfc https://wiki.php.net/rfc/immutability > > Cheers > -1 from my side for all the things previously mentioned. The copy-on-write topic must be solved along with the introduction of immutable classes or we

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Silvio Marijić
Hi, this would be basic implementation of 'modify' function which would operate on cloned object PHP_FUNCTION(modify) { zval *obj, *properties, *entry; zend_long h; zend_string *key; if (zend_parse_parameters(ZEND_NUM_ARGS(), "oa", , ) == FAILURE) { return; }

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

2016-12-12 Thread Derick Rethans
On Mon, 12 Dec 2016, Leigh wrote: > Ok rookie PECL mistake here. > > I was adding Derick and Sascha as leads (as they were the original leads) > and demoting myself to helper (not knowing it was required to further > maintain the package). So I have locked myself out :) > > Could you add me

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-12-11

2016-12-12 Thread lp_benchmark_robot
Results for project PHP master, build date 2016-12-11 20:28:57-08:00 commit: 32201fe previous commit:4fc3944 revision date: 2016-12-12 01:57:31+01:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] More secure defaults for openssl_public_encrypt() & openssl_private_decrypt()

2016-12-12 Thread Andreas Heigl
Am 12.12.16 um 16:26 schrieb Sammy Kaye Powers: > Hey internals! > > As pointed out in Paragon's excellent blog post, > openssl_public_encrypt() & openssl_private_decrypt() defaults to the > insecure OPENSSL_PKCS1_PADDING constant. > >

Re: [PHP-DEV] More secure defaults for openssl_public_encrypt() & openssl_private_decrypt()

2016-12-12 Thread Scott Arciszewski
On Mon, Dec 12, 2016 at 10:26 AM, Sammy Kaye Powers wrote: > Hey internals! > > As pointed out in Paragon's excellent blog post, > openssl_public_encrypt() & openssl_private_decrypt() defaults to the > insecure OPENSSL_PKCS1_PADDING constant. > >

[PHP-DEV] More secure defaults for openssl_public_encrypt() & openssl_private_decrypt()

2016-12-12 Thread Sammy Kaye Powers
Hey internals! As pointed out in Paragon's excellent blog post, openssl_public_encrypt() & openssl_private_decrypt() defaults to the insecure OPENSSL_PKCS1_PADDING constant.

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

2016-12-12 Thread Leigh
Ok rookie PECL mistake here. I was adding Derick and Sascha as leads (as they were the original leads) and demoting myself to helper (not knowing it was required to further maintain the package). So I have locked myself out :) Could you add me back as a lead to the pecl package please, so I can

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Silvio Marijić
2016-12-12 15:14 GMT+01:00 Rowan Collins : > On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" < > marijic.sil...@gmail.com> wrote: > >Regarding my proposal above, since copy() would essentially operate > >only on > >immutable objects, why not put it only there. So

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Silvio Marijić
2016-12-12 15:14 GMT+01:00 Rowan Collins : > On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" < > marijic.sil...@gmail.com> wrote: > >Regarding my proposal above, since copy() would essentially operate > >only on > >immutable objects, why not put it only there. So

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Rowan Collins
On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" wrote: >Regarding my proposal above, since copy() would essentially operate >only on >immutable objects, why not put it only there. So you would be able to >make >a call like this one $immutable->copy(array

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

2016-12-12 Thread Silvio Marijić
@Davey, There was similar suggestion that $this represents clone of the object. I think that is a bit vague, and I'am not sure about the 'scope' you refer to because 'double scoping' could be also a reason to downvote this rfc and it can lead to confusion in my opinion. I will check HHVM also.