On 31/12/2020 14:04, Olle Härstedt wrote:
Yes, of course you can find use-cases where immutability is a better choice, just like I can find use-cases where (constrained) mutability is better. The point is not to replace one tool with another, but rather adding another tool to the toolbox. The web dev discourse is one-sided with regard to immutability, I think. Wish I had time to implement a PR to Psalm to show something more concrete... Again, if you only have a hammer, everything looks like a nail. :)
Certainly, I didn't mean to say that immutability was always the perfect choice. I think it's popular because it's an easy hammer to borrow from the fashionable Functional Programming toolbox - you can get a lot of its advantages without much support from the language, and it genuinely fits a lot of use cases encountered in high-level programming.
Where ownership concepts seem to shine is where immutability is either impossible (e.g. consuming from a network stream or an event queue) or otherwise undesirable (e.g. working with large amounts of data, or tightly optimised code).
I read a bit about Uniqueness Attributes in Clean [1] and it seems they are implemented there so that the *user* can treat everything as immutable, but the *compiler* can safely mutate underlying structures. So in that implementation at least, a "mutable record" would in fact be implemented with the equivalent of "clone ... with", so that it appeared *from the outside* to return a new instance each time.
It's certainly an interesting concept, particularly for the I/O case (where immutability is genuinely not an option) but how easy it would be to retro-fit to a dynamic language like PHP I'm not sure.
[1] https://cloogle.org/doc/#_9 Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
