Re: [RFC][DISCUSSION] Immutability

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