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ć <marijic.sil...@gmail.com> 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ć" <marijic.sil...@gmail.com> 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.sil...@gmail.com wrote: >> >> Yes, I've also took that into consideration when choosing keyword. >> >> On Feb 26, 2018 11:35 AM, "Crocodile" <crocodil...@gmail.com> 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 <pmjone...@gmail.com> wrote: >> >>> >>> >>> > On Feb 25, 2018, at 12:59, Silvio Marijić <marijic.sil...@gmail.com> >>> 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 >>> pmjo...@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
