On 11 July 2020 16:13:24 BST, "Olle Härstedt" <olleharst...@gmail.com> wrote: >Yes, the point is to be limiting. :) Just like with immutability, you >apply certain limitations to avoid access abuse.
Taken to extremes, this is the "secure a server by encasing it in concrete" strategy - the hard part about designing useful limitations is not the parts you want to make impossible, it's the parts you want to remain easy. There is a reason Rust has a whole set of mechanisms for managing ownership, not just a single "mine/yours" split, because they allow the programmer to express what they want to do with the object. >Regarding "freezing" an object, I actually already wrote about this in >a blog post, using dependency injection as a use-case, and a trait to >add a method to check the refcount: >http://olleharstedt.github.io/php/2020/07/08/immutable-at-borrow.html The difference in my mind between freezing an object and tracking ownership is that "frozen/unfrozen" would be an explicit state set on the object, not a measurement that differs as it is used. So either the user says "freeze $object", and it is then immutable for the rest of the program, or some point after construction implicitly freezes it with the same effect. This eliminates the dependence on tracking ownership or giving meaning to the refcount, because no matter how you received the object, you must no longer cause it to be mutated. It also has much lower performance impact. Even the automatic form can probably be performed by the compiler - e.g. if "new" was called in this function, insert a call to "freeze" before the first time the object appears as a function parameter Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
