Welcome! Log In Create A New Profile

Advanced

[PHP-DEV][RFC][DISCUSSION] Immutability

Posted by Silvio Marijić 
Silvio Marijić
[PHP-DEV][RFC][DISCUSSION] Immutability
February 20, 2018 12:30PM
Hi,
I am starting this discussion again after a year since this RFC was
created. From discussions with people in the community some suggestions
came up regarding issues that were main reason that development on this RFC
stopped. RFC is updated along with implementation (link at the bottom of
RFC). I'll be more then happy to answer all questions.

--
Silvio Marijić
Software Engineer
SMSGlobal
Nikita Popov
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 20, 2018 12:30PM
On Tue, Feb 20, 2018 at 12:20 PM, Silvio Marijić <[email protected]>
wrote:

> Hi,
> I am starting this discussion again after a year since this RFC was
> created. From discussions with people in the community some suggestions
> came up regarding issues that were main reason that development on this RFC
> stopped. RFC is updated along with implementation (link at the bottom of
> RFC). I'll be more then happy to answer all questions.


Link: https://wiki.php.net/rfc/immutability :)

Nikita
Rowan Collins
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 22, 2018 11:00AM
On 20 February 2018 at 11:25, Nikita Popov <[email protected]> wrote:

> On Tue, Feb 20, 2018 at 12:20 PM, Silvio Marijić <[email protected]
> >
> wrote:
>
> > Hi,
> > I am starting this discussion again after a year since this RFC was
> > created. From discussions with people in the community some suggestions
> > came up regarding issues that were main reason that development on this
> RFC
> > stopped. RFC is updated along with implementation (link at the bottom of
> > RFC). I'll be more then happy to answer all questions.
>
>
> Link: https://wiki.php.net/rfc/immutability :)



This definitely seems like an exciting addition to the language. Some
clarifications:


This sentence in the RFC is rather confusing, "Any references to objects
.... cannot be references to scalars ... or may be ...". I think it's just
reiterating things said elsewhere in the RFC, but could maybe be reworded?

> Any references to objects passed into an immutable class constructor
cannot be references to scalars or may be immutable class instances.

A set of bullet points of what types can and can't be assigned to an
immutable property might be useful.


The example under "references" shows a reference being successfully taken
to an immutable property, but then being considered immutable itself. Is
there any performance penalty to tracking this extra state? I know
references have caused problems in other cases, like the typed properties
RFC.


What kind of error is produced when you attempt to write to an immutable
property? I would expect some sub-class of Error to be thrown, but the RFC
currently just says a fatal error.

As I say, I like the idea, and thanks for working on it.

Regards,
--
Rowan Collins
[IMSoP]
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 02:50PM
Hi Rowan,

I agree that RFC needs a bit refinement which I hope to do during ongoing
discussion here.
Originally you couldn't assign following types to an immutable property

- *Resource*
- *Instance of none-immutable class *

Now I had to resort to also add *array* to that list.


Regarding your question about references, yes you can obtain reference to
an immutable property but you can not modify that property by reference. In
that case it will throw fatal error, but I agree that it would be better to
throw exception, I will include that in RFC.

Thanks for the support I really appreciate it.

Regards,

2018-02-22 10:57 GMT+01:00 Rowan Collins <[email protected]>:

> On 20 February 2018 at 11:25, Nikita Popov <[email protected]> wrote:
>
> > On Tue, Feb 20, 2018 at 12:20 PM, Silvio Marijić <
> marijic.silvio@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > > I am starting this discussion again after a year since this RFC was
> > > created. From discussions with people in the community some suggestions
> > > came up regarding issues that were main reason that development on this
> > RFC
> > > stopped. RFC is updated along with implementation (link at the bottom
> of
> > > RFC). I'll be more then happy to answer all questions.
> >
> >
> > Link: https://wiki.php.net/rfc/immutability :)
>
>
>
> This definitely seems like an exciting addition to the language. Some
> clarifications:
>
>
> This sentence in the RFC is rather confusing, "Any references to objects
> ... cannot be references to scalars ... or may be ...". I think it's just
> reiterating things said elsewhere in the RFC, but could maybe be reworded?
>
> > Any references to objects passed into an immutable class constructor
> cannot be references to scalars or may be immutable class instances.
>
> A set of bullet points of what types can and can't be assigned to an
> immutable property might be useful.
>
>
> The example under "references" shows a reference being successfully taken
> to an immutable property, but then being considered immutable itself. Is
> there any performance penalty to tracking this extra state? I know
> references have caused problems in other cases, like the typed properties
> RFC.
>
>
> What kind of error is produced when you attempt to write to an immutable
> property? I would expect some sub-class of Error to be thrown, but the RFC
> currently just says a fatal error.
>
> As I say, I like the idea, and thanks for working on it.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>



--
Silvio Marijić
Software Engineer
SMSGlobal
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 02:50PM
In addition to your question about impact on the performance, there is
none. As there is no special tracking of those references just control
check when you try to write by reference.

2018-02-23 14:40 GMT+01:00 Silvio Marijić <[email protected]>:

> Hi Rowan,
>
> I agree that RFC needs a bit refinement which I hope to do during ongoing
> discussion here.
> Originally you couldn't assign following types to an immutable property
>
> - *Resource*
> - *Instance of none-immutable class *
>
> Now I had to resort to also add *array* to that list.
>
>
> Regarding your question about references, yes you can obtain reference to
> an immutable property but you can not modify that property by reference. In
> that case it will throw fatal error, but I agree that it would be better to
> throw exception, I will include that in RFC.
>
> Thanks for the support I really appreciate it.
>
> Regards,
>
> 2018-02-22 10:57 GMT+01:00 Rowan Collins <[email protected]>:
>
>> On 20 February 2018 at 11:25, Nikita Popov <[email protected]> wrote:
>>
>> > On Tue, Feb 20, 2018 at 12:20 PM, Silvio Marijić <
>> marijic.silvio@gmail.com
>> > >
>> > wrote:
>> >
>> > > Hi,
>> > > I am starting this discussion again after a year since this RFC was
>> > > created. From discussions with people in the community some
>> suggestions
>> > > came up regarding issues that were main reason that development on
>> this
>> > RFC
>> > > stopped. RFC is updated along with implementation (link at the bottom
>> of
>> > > RFC). I'll be more then happy to answer all questions.
>> >
>> >
>> > Link: https://wiki.php.net/rfc/immutability :)
>>
>>
>>
>> This definitely seems like an exciting addition to the language. Some
>> clarifications:
>>
>>
>> This sentence in the RFC is rather confusing, "Any references to objects
>> ... cannot be references to scalars ... or may be ...". I think it's just
>> reiterating things said elsewhere in the RFC, but could maybe be reworded?
>>
>> > Any references to objects passed into an immutable class constructor
>> cannot be references to scalars or may be immutable class instances.
>>
>> A set of bullet points of what types can and can't be assigned to an
>> immutable property might be useful.
>>
>>
>> The example under "references" shows a reference being successfully taken
>> to an immutable property, but then being considered immutable itself. Is
>> there any performance penalty to tracking this extra state? I know
>> references have caused problems in other cases, like the typed properties
>> RFC.
>>
>>
>> What kind of error is produced when you attempt to write to an immutable
>> property? I would expect some sub-class of Error to be thrown, but the RFC
>> currently just says a fatal error.
>>
>> As I say, I like the idea, and thanks for working on it.
>>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>>
>
>
>
> --
> Silvio Marijić
> Software Engineer
> SMSGlobal
>



--
Silvio Marijić
Software Engineer
SMSGlobal
Paul Jones
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 03:10PM
Hi Silvio,

I like the RFC.

* * *

I would like to see arrays allowed as immutable properties.

In http://paul-m-jones.com/archives/6400 I wrote that arrays are "probably not practical in most situations" because you have to "recursively scan through array properties to make sure that they contain only immutable values".

However, I think if the scanning happens at the C level it is not such a burden. John Boehr implemented it for the immutable ServerRequest object in ext-request http://pecl.php.net/package/request and it has worked well.

If you do allow arrays, they would have to follow the same rules as the immutable object.

Alternatively, perhaps an ImmutableArrayObject would be a good addition or followup to the RFC.

* * *

Some further points to harden the implementation:

- I see that resources and references are disallowed (which is good). If you have not already done so, you may wish to disallow streams as well.

- You might want to disable setting of undefined public properties, so that you cannot "add" mutable public properties to the immutable object.

- Disable the constructor after it has been called, so the object cannot be "re-constructed" in place.

* * *

That's all I can think of for now. Thanks for putting this together.


--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 03:30PM
Thanks Paul,

I do have rough idea how to go about arrays possibly without recursive
scan, I have to try couple of things, it could work if some checks are
moved to zval level. For now it is in the future scope unless I manage to
handle the within week or two.

First two proposals are valid points. Regarding disabling constructor, that
would fail as soon as you try to write properties in constructor since
object is already "locked".

Best regards and thanks for proposals.

2018-02-23 15:08 GMT+01:00 Paul Jones <[email protected]>:

> Hi Silvio,
>
> I like the RFC.
>
> * * *
>
> I would like to see arrays allowed as immutable properties.
>
> In http://paul-m-jones.com/archives/6400 I wrote that arrays are
> "probably not practical in most situations" because you have to
> "recursively scan through array properties to make sure that they contain
> only immutable values".
>
> However, I think if the scanning happens at the C level it is not such a
> burden. John Boehr implemented it for the immutable ServerRequest object in
> ext-request http://pecl.php.net/package/request and it has worked well.
>
> If you do allow arrays, they would have to follow the same rules as the
> immutable object.
>
> Alternatively, perhaps an ImmutableArrayObject would be a good addition or
> followup to the RFC.
>
> * * *
>
> Some further points to harden the implementation:
>
> - I see that resources and references are disallowed (which is good). If
> you have not already done so, you may wish to disallow streams as well.
>
> - You might want to disable setting of undefined public properties, so
> that you cannot "add" mutable public properties to the immutable object.
>
> - Disable the constructor after it has been called, so the object cannot
> be "re-constructed" in place.
>
> * * *
>
> That's all I can think of for now. Thanks for putting this together.
>
>
> --
> Paul M. Jones
> pmjones@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
>


--
Silvio Marijić
Software Engineer
SMSGlobal
Niklas Keller
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 03:50PM
Hey,

> If you do allow arrays, they would have to follow the same rules as the immutable object.
>
> Alternatively, perhaps an ImmutableArrayObject would be a good addition or followup to the RFC.

That would just move the problem and doesn't have any benefit over
directly allowing arrays, right?

> Some further points to harden the implementation:
>
> - I see that resources and references are disallowed (which is good). If you have not already done so, you may wish to disallow streams as well.

Streams are resources, am I missing something?

Regards, Niklas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 03:50PM
Hey,

> I do have rough idea how to go about arrays possibly without recursive
> scan, I have to try couple of things, it could work if some checks are
> moved to zval level. For now it is in the future scope unless I manage to
> handle the within week or two.

What's the issue with a one-time runtime check on assignment?

> First two proposals are valid points. Regarding disabling constructor, that
> would fail as soon as you try to write properties in constructor since
> object is already "locked".

You lock the object after the constructor has been called, not
afterwards. If you don't do that, your objects won't be immutable.

I like the RFC, but generally I think value objects that are passed
by-value instead of by-reference are the better way to solve the
problem.

Regards, Niklas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 05:10PM
Hi Niklas,

Problem with checking array on assignment is that it could be N dimensions
deep and one would have perform check for each item in each dimension for
mutable values which could have some performance implications.
Regarding constructor call, upon first initialization of object, you are
allowed to assign values to properties, after constructor is executed,
object is locked. If you try to call again constructor on the same object
it would fail as soon as execution reaches first assignment statement
because object was already marked as locked.

I agree that it would be better to pass by value but I am not sure how
would that impact the way we currently manage objects in object store.

Best regards,

2018-02-23 15:47 GMT+01:00 Niklas Keller <[email protected]>:

> Hey,
>
> > I do have rough idea how to go about arrays possibly without recursive
> > scan, I have to try couple of things, it could work if some checks are
> > moved to zval level. For now it is in the future scope unless I manage to
> > handle the within week or two.
>
> What's the issue with a one-time runtime check on assignment?
>
> > First two proposals are valid points. Regarding disabling constructor,
> that
> > would fail as soon as you try to write properties in constructor since
> > object is already "locked".
>
> You lock the object after the constructor has been called, not
> afterwards. If you don't do that, your objects won't be immutable.
>
> I like the RFC, but generally I think value objects that are passed
> by-value instead of by-reference are the better way to solve the
> problem.
>
> Regards, Niklas
>



--
Silvio Marijić
Software Engineer
SMSGlobal
Niklas Keller
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 07:30PM
Hey,

> Problem with checking array on assignment is that it could be N dimensions
> deep and one would have perform check for each item in each dimension for
> mutable values which could have some performance implications.

if you want to enforce that in userland now, you have even higher
performance implications. I wouldn't worry about the performance of
edge cases and take away a feature for everybody else because of that.

If there's a better internal implementation, it can always be improved later.

> Regarding constructor call, upon first initialization of object, you are
> allowed to assign values to properties, after constructor is executed,
> object is locked. If you try to call again constructor on the same object it
> would fail as soon as execution reaches first assignment statement because
> object was already marked as locked.

Sounds good! So it's already implemented basically.

> I agree that it would be better to pass by value but I am not sure how would
> that impact the way we currently manage objects in object store.

If we both agree it would be the better way, why not draft an RFC for
it and find someone who knows how to implement it?

Regards, Niklas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 23, 2018 08:10PM
I agree that for any real world applications it wouldn't affect
performance, I just didn't want to leave any holes in implementation.
Ill test couple of solutions for arrays to see how it works.

Yeah, checks are also in place for multiple constructor calls.

Regarding your suggestion to draft RFC for passing by value of immutable
objects, I am up for that if this RFC passes voting.

2018-02-23 19:23 GMT+01:00 Niklas Keller <[email protected]>:

> Hey,
>
> > Problem with checking array on assignment is that it could be N
> dimensions
> > deep and one would have perform check for each item in each dimension for
> > mutable values which could have some performance implications.
>
> if you want to enforce that in userland now, you have even higher
> performance implications. I wouldn't worry about the performance of
> edge cases and take away a feature for everybody else because of that.
>
> If there's a better internal implementation, it can always be improved
> later.
>
> > Regarding constructor call, upon first initialization of object, you are
> > allowed to assign values to properties, after constructor is executed,
> > object is locked. If you try to call again constructor on the same
> object it
> > would fail as soon as execution reaches first assignment statement
> because
> > object was already marked as locked.
>
> Sounds good! So it's already implemented basically.
>
> > I agree that it would be better to pass by value but I am not sure how
> would
> > that impact the way we currently manage objects in object store.
>
> If we both agree it would be the better way, why not draft an RFC for
> it and find someone who knows how to implement it?
>
> Regards, Niklas
>



--
Silvio Marijić
Software Engineer
SMSGlobal
Dan Ackroyd
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 25, 2018 06:00PM
On 23 February 2018 at 13:47, Silvio Marijić <[email protected]> wrote:
> In addition to your question about impact on the performance, there is
> none.

Have you actually measured that there is no performance impact, or is
that an assumption from what affect the code should have?

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 25, 2018 06:30PM
Hi Dan,

So far that is still only assumption made based on the fact that most of
the code for protecting state is composed of bit checks but I am definitely
interested to see benchmark for this RFC.

Best regards,

On Feb 25, 2018 5:49 PM, "Dan Ackroyd" <[email protected]> wrote:

On 23 February 2018 at 13:47, Silvio Marijić <[email protected]>
wrote:
> In addition to your question about impact on the performance, there is
> none.

Have you actually measured that there is no performance impact, or is
that an assumption from what affect the code should have?

cheers
Dan
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 25, 2018 06:40PM
I had discussion on Twitter regarding semantics of keyword 'immutable'.

I am considering now to replace keyword 'immutable' with 'value'.

How would you compare those two, which one is more suitable here?

On Feb 25, 2018 6:24 PM, "Silvio Marijić" <[email protected]> wrote:

> Hi Dan,
>
> So far that is still only assumption made based on the fact that most of
> the code for protecting state is composed of bit checks but I am definitely
> interested to see benchmark for this RFC.
>
> Best regards,
>
> On Feb 25, 2018 5:49 PM, "Dan Ackroyd" <[email protected]> wrote:
>
> On 23 February 2018 at 13:47, Silvio Marijić <[email protected]>
> wrote:
> > In addition to your question about impact on the performance, there is
> > none.
>
> Have you actually measured that there is no performance impact, or is
> that an assumption from what affect the code should have?
>
> cheers
> Dan
>
>
>
Paul Jones
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 25, 2018 08:00PM
> On Feb 25, 2018, at 11:29, Silvio Marijić <[email protected]> wrote:
>
> I had discussion on Twitter regarding semantics of keyword 'immutable'.

Can you link to the discussion? I am interested to read it.


--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 25, 2018 08:10PM
Here is link to tweet
https://twitter.com/SilvioMarijic/status/965564630071300096

2018-02-25 19:53 GMT+01:00 Paul Jones <[email protected]>:

>
>
> > On Feb 25, 2018, at 11:29, Silvio Marijić <[email protected]>
> wrote:
> >
> > I had discussion on Twitter regarding semantics of keyword 'immutable'.
>
> Can you link to the discussion? I am interested to read it.
>
>
> --
> Paul M. Jones
> pmjones@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
>


--
Silvio Marijić
Software Engineer
SMSGlobal
Paul Jones
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 25, 2018 08:10PM
> On Feb 25, 2018, at 12:59, Silvio Marijić <[email protected]> wrote:
>
> Here is link to tweet https://twitter.com/SilvioMarijic/status/965564630071300096

After having read that, I think "immutable" is still perfectly reasonable.


--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Crocodile
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 26, 2018 11:40AM
Is "value" or "immutable" going to become a new reserved word? Ain't we
going to have some BC breaks because of that? If so, then "value" is going
to bring more BC breaks then "immutable".

On Sun, Feb 25, 2018 at 8:02 PM Paul Jones <[email protected]> wrote:

>
>
> > On Feb 25, 2018, at 12:59, Silvio Marijić <[email protected]>
> wrote:
> >
> > Here is link to tweet
> https://twitter.com/SilvioMarijic/status/965564630071300096
>
> After having read that, I think "immutable" is still perfectly reasonable..
>
>
> --
> Paul M. Jones
> pmjones@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 26, 2018 01:50PM
Yes, I've also took that into consideration when choosing keyword.

On Feb 26, 2018 11:35 AM, "Crocodile" <[email protected]> wrote:

> Is "value" or "immutable" going to become a new reserved word? Ain't we
> going to have some BC breaks because of that? If so, then "value" is going
> to bring more BC breaks then "immutable".
>
> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones <[email protected]> wrote:
>
>>
>>
>> > On Feb 25, 2018, at 12:59, Silvio Marijić <[email protected]>
>> wrote:
>> >
>> > Here is link to tweet https://twitter.com/SilvioMarijic/status/
>> 965564630071300096
>>
>> After having read that, I think "immutable" is still perfectly reasonable.
>>
>>
>> --
>> Paul M. Jones
>> pmjones@pmjones.io
>> http://paul-m-jones.com
>>
>> Modernizing Legacy Applications in PHP
>> https://leanpub.com/mlaphp
>>
>> Solving the N+1 Problem in PHP
>> https://leanpub.com/sn1php
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>> --
> Best regards,
> Victor Bolshov
>
Silvio Marijić
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 26, 2018 02:00PM
Currently the build is failing in some parts of the codebase that are
obviously affected in some way.
I ran valgrind for couple of failing tests and I got numerous reports about
memory leaks and conditional jumps over uninitialized values.
Not sure what is the reason for that, I had merge conflict with upstream
master couple days ago, might be a reason.

I would appreciate if anyone could give me hand on this ?

On Feb 26, 2018 1:48 PM, "Silvio Marijić" <[email protected]> wrote:

> Currently the build is failing in some parts of the codebase that are
> obviously affected in some way.
> I ran valgrind for couple of failing tests and I got numerous reports
> about memory leaks and conditional jumps over uninitialized values.
> Not sure what is the reason for that, I had merge conflict with upstream
> master couple days ago, might be a reason.
>
> I would appreciate if anyone could give me hand on this ?
>
> On Feb 26, 2018 1:44 PM, marijic.silvio@gmail.com wrote:
>
> Yes, I've also took that into consideration when choosing keyword.
>
> On Feb 26, 2018 11:35 AM, "Crocodile" <[email protected]> wrote:
>
> Is "value" or "immutable" going to become a new reserved word? Ain't we
> going to have some BC breaks because of that? If so, then "value" is going
> to bring more BC breaks then "immutable".
>
> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones <[email protected]> wrote:
>
>>
>>
>> > On Feb 25, 2018, at 12:59, Silvio Marijić <[email protected]>
>> wrote:
>> >
>> > Here is link to tweet https://twitter.com/SilvioMari
>> jic/status/965564630071300096
>>
>> After having read that, I think "immutable" is still perfectly reasonable.
>>
>>
>> --
>> Paul M. Jones
>> pmjones@pmjones.io
>> http://paul-m-jones.com
>>
>> Modernizing Legacy Applications in PHP
>> https://leanpub.com/mlaphp
>>
>> Solving the N+1 Problem in PHP
>> https://leanpub.com/sn1php
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>> --
> Best regards,
> Victor Bolshov
>
>
>
>
Andreas Hennings
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 26, 2018 04:20PM
Hello,
my thoughts.
For me personally the proposed feature would not be very useful.
i like immutable objects. But for me the pattern of choice is private
properties + constructor + optional "wither" methods.

The "wither" methods create a clone of the object, then set a property
value on the clone, then return the clone.
This would already not work if the property is marked as immutable
with the proposed feature.

Also static method constructors that write directly on the object
would not work, because technically they are not part of the
constructor.

For private properties the proposed feature would add little benefit.
Any private property can be made practically immutable by writing the
class accordingly: Not having setters, etc.

Where this feature would become useful is if someone prefers public
properties over getter methods.
But again, this would prevent any unconventional constructor, like
withers or static factories.

I think a better and more useful feature would be read-public, write-private.
Maybe like this? https://wiki.php.net/rfc/readonly_properties
(For some reason I cannot open the RFC wiki pages. Maybe they are down?)

This would achieve the same goal: Making a property practically immutable.
But it would still allow unconventional constructors.
It would be the implementor's job to decide which method should be
allowed to modify a property, and which shouldn't.



On 26 February 2018 at 13:52, Silvio Marijić <[email protected]> wrote:
> Currently the build is failing in some parts of the codebase that are
> obviously affected in some way.
> I ran valgrind for couple of failing tests and I got numerous reports about
> memory leaks and conditional jumps over uninitialized values.
> Not sure what is the reason for that, I had merge conflict with upstream
> master couple days ago, might be a reason.
>
> I would appreciate if anyone could give me hand on this ?
>
> On Feb 26, 2018 1:48 PM, "Silvio Marijić" <[email protected]> wrote:
>
>> Currently the build is failing in some parts of the codebase that are
>> obviously affected in some way.
>> I ran valgrind for couple of failing tests and I got numerous reports
>> about memory leaks and conditional jumps over uninitialized values.
>> Not sure what is the reason for that, I had merge conflict with upstream
>> master couple days ago, might be a reason.
>>
>> I would appreciate if anyone could give me hand on this ?
>>
>> On Feb 26, 2018 1:44 PM, marijic.silvio@gmail.com wrote:
>>
>> Yes, I've also took that into consideration when choosing keyword.
>>
>> On Feb 26, 2018 11:35 AM, "Crocodile" <[email protected]> wrote:
>>
>> Is "value" or "immutable" going to become a new reserved word? Ain't we
>> going to have some BC breaks because of that? If so, then "value" is going
>> to bring more BC breaks then "immutable".
>>
>> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones <[email protected]> wrote:
>>
>>>
>>>
>>> > On Feb 25, 2018, at 12:59, Silvio Marijić <[email protected]>
>>> wrote:
>>> >
>>> > Here is link to tweet https://twitter.com/SilvioMari
>>> jic/status/965564630071300096
>>>
>>> After having read that, I think "immutable" is still perfectly reasonable.
>>>
>>>
>>> --
>>> Paul M. Jones
>>> pmjones@pmjones.io
>>> http://paul-m-jones.com
>>>
>>> Modernizing Legacy Applications in PHP
>>> https://leanpub.com/mlaphp
>>>
>>> Solving the N+1 Problem in PHP
>>> https://leanpub.com/sn1php
>>>
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>> --
>> Best regards,
>> Victor Bolshov
>>
>>
>>
>>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Crocodile
Re: [PHP-DEV][RFC][DISCUSSION] Immutability
February 26, 2018 05:00PM
Nice one by Andreas Hennings, I think! I personally have also question on
deserialization of immutables. Is it going to be possible at all?

Another thing is that PDO will probably not be able to use FETCH_CLASS with
immutables, because of the way it initializes properties.

On Mon, Feb 26, 2018 at 4:13 PM Andreas Hennings <[email protected]>
wrote:

> Hello,
> my thoughts.
> For me personally the proposed feature would not be very useful.
> i like immutable objects. But for me the pattern of choice is private
> properties + constructor + optional "wither" methods.
>
> The "wither" methods create a clone of the object, then set a property
> value on the clone, then return the clone.
> This would already not work if the property is marked as immutable
> with the proposed feature.
>
> Also static method constructors that write directly on the object
> would not work, because technically they are not part of the
> constructor.
>
> For private properties the proposed feature would add little benefit.
> Any private property can be made practically immutable by writing the
> class accordingly: Not having setters, etc.
>
> Where this feature would become useful is if someone prefers public
> properties over getter methods.
> But again, this would prevent any unconventional constructor, like
> withers or static factories.
>
> I think a better and more useful feature would be read-public,
> write-private.
> Maybe like this? https://wiki.php.net/rfc/readonly_properties
> (For some reason I cannot open the RFC wiki pages. Maybe they are down?)
>
> This would achieve the same goal: Making a property practically immutable..
> But it would still allow unconventional constructors.
> It would be the implementor's job to decide which method should be
> allowed to modify a property, and which shouldn't.
>
>
>
> On 26 February 2018 at 13:52, Silvio Marijić <[email protected]>
> wrote:
> > Currently the build is failing in some parts of the codebase that are
> > obviously affected in some way.
> > I ran valgrind for couple of failing tests and I got numerous reports
> about
> > memory leaks and conditional jumps over uninitialized values.
> > Not sure what is the reason for that, I had merge conflict with upstream
> > master couple days ago, might be a reason.
> >
> > I would appreciate if anyone could give me hand on this ?
> >
> > On Feb 26, 2018 1:48 PM, "Silvio Marijić" <[email protected]>
> wrote:
> >
> >> Currently the build is failing in some parts of the codebase that are
> >> obviously affected in some way.
> >> I ran valgrind for couple of failing tests and I got numerous reports
> >> about memory leaks and conditional jumps over uninitialized values.
> >> Not sure what is the reason for that, I had merge conflict with upstream
> >> master couple days ago, might be a reason.
> >>
> >> I would appreciate if anyone could give me hand on this ?
> >>
> >> On Feb 26, 2018 1:44 PM, marijic.silvio@gmail.com wrote:
> >>
> >> Yes, I've also took that into consideration when choosing keyword.
> >>
> >> On Feb 26, 2018 11:35 AM, "Crocodile" <[email protected]> wrote:
> >>
> >> Is "value" or "immutable" going to become a new reserved word? Ain't we
> >> going to have some BC breaks because of that? If so, then "value" is
> going
> >> to bring more BC breaks then "immutable".
> >>
> >> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones <[email protected]> wrote:
> >>
> >>>
> >>>
> >>> > On Feb 25, 2018, at 12:59, Silvio Marijić <[email protected]>
> >>> wrote:
> >>> >
> >>> > Here is link to tweet https://twitter.com/SilvioMari
> >>> jic/status/965564630071300096
> >>>
> >>> After having read that, I think "immutable" is still perfectly
> reasonable.
> >>>
> >>>
> >>> --
> >>> Paul M. Jones
> >>> pmjones@pmjones.io
> >>> http://paul-m-jones.com
> >>>
> >>> Modernizing Legacy Applications in PHP
> >>> https://leanpub.com/mlaphp
> >>>
> >>> Solving the N+1 Problem in PHP
> >>> https://leanpub.com/sn1php
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>> --
> >> Best regards,
> >> Victor Bolshov
> >>
> >>
> >>
> >>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov
Sorry, only registered users may post in this forum.

Click here to login