Re: Analysis of property visibility, immutability, and cloning proposals

Hi Rowan and all, I apologize in advance for the wall-of-text; the short questions lead to long answers. > On Jan 2, 2021, at 12:56, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On 01/01/2021 20:31, Paul M. Jones wrote: > >> The complaints against the incomplete and inconsistent immutability of PSR-7 have merit. > > The big mistake of PSR-7, in my view, is mixing immutable objects with streams, which are > inherently mutable/stateful. (/me nods along) Streams were noted as the one explicit exception to immutability in PSR-7. Looking back on it, that should have been a sign to us that immutability should not have been a goal. (Re: PSR-7 but not re: immutability, there is at least one more mistake born of the original intent, that seemed reasonable at the time but in hindsight was another poor decision: it combines the concerns of the HTTP message with the concerns of middleware communication. This observation is attributable to [deleted] at Reddit ... https://www.reddit.com/r/PHP/comments/5ojqr0/q_how_many_psr7_implementations_exist_a_zero/dcjxtxl/ ... stating "[T]he true intent of PSR-7 [is] not to be an HTTP message standard, but to be middleware IO standard, which happens to be mostly (but not only) an HTTP message." It's an accurate assessment.) > I wonder if there are any lessons to be learned there in terms of what kinds of immutability > the language should encourage / make easy. I think there are; I wrote about at least some of them here ... https://paul-m-jones.com/post/2016/09/06/avoiding-quasi-immutable-objects-in-php/ ... in which I conclude that, if you want to build a truly immutable object in PHP, it appears the best approach is the following: - Default to using only scalars and nulls as properties. - Avoid streams as properties; if a property must be a stream, make sure that it is read-only, and that its state is restored each time it is used. - Avoid objects as properties; if a property must be an object, make sure that object is itself immutable. - Especially avoid arrays as properties; use only with extreme caution and care. - Implement __set() to disallow setting of undefined properties. - Possibly implement __unset() to warn that the object is immutable. I put those conclusions (and other resulting from that article) into an implementation described here: http://paul-m-jones.com/post/2019/02/04/immutability-package-for-php/ > is it better to constrain entire objects to be immutable rather than individual properties? I would say that the entire object ought to be immutable, for reasons that are difficult for me to articulate. > And should there be restrictions on what you can declare as immutable, since "immutable > resource" is largely nonsensical? I think so, and I note some of those restrictions above. In particular, the immutability package ValueObject further inspects arrays to restrict their values to immutables as well. -- 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