@Fleshgrinder My opinion on that subject is still that features are mostly complete but I'am willing to find also solution to ease modifying. Modify function does not modify object in any way, it will operate on the clone of the object and this was just prototype. Moreover it should be restricted to be only callable from the scope of the object. Introducing method modifier causes more problems then it solves, and has whole another level of complexity. Regarding changing keyword, 'data' does not fit because object is behaviour + data, with behaviour beeing (or at least it should be) at the first place. Value can imply or create confusion with Value Objects, on the other hand immutable clearly states what it is.
Cheers, 2016-12-12 19:44 GMT+01:00 Fleshgrinder <p...@fleshgrinder.com>: > On 12/11/2016 5:57 PM, Silvio Marijić wrote: > > Hi, > > > > Discussion is open for following rfc https://wiki.php.net/rfc/ > immutability > > > > Cheers > > > > -1 from my side for all the things previously mentioned. The > copy-on-write topic must be solved along with the introduction of > immutable classes or we end up with this being implemented and not way > to mutate them in a controlled fashion. > > Also -1 on the proposed `copy` or `modify` function. Not only does it > seem to allow anyone to mutate the immutable object, it also requires > magic strings of the property names. No usage search, no refactoring, no > ... > > I still strongly believe that `__clone` should be made `private` or > `protected` for immutable classes to avoid useless cloning. After that > we either stick to cloning as we currently do in our `with*` methods or > we provide a keyword that changes the behavior of a method. > > I also propose to use `data` or `value` instead of `immutable` as the > class modifier keyword. Its shorter and properly as well as fully > communicates what kind of object we are building. > > -- > Richard "Fleshgrinder" Fussenegger > -- Silvio Marijić Software Engineer 2e Systems
