> 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
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
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 ?
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
@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
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
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;
}
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
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
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.
>
>
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.
>
>
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.
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
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
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
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
@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.
17 matches
Mail list logo