2016-12-12 15:14 GMT+01:00 Rowan Collins <rowan.coll...@gmail.com>: > On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" < > marijic.sil...@gmail.com> wrote: > >Regarding my proposal above, since copy() would essentially operate > >only on > >immutable objects, why not put it only there. So you would be able to > >make > >a call like this one $immutable->copy(array $args); or > >$this->copy(array > >$args); depending on whether you are inside let's say with* method or > >outside of the object. > > If users of the object can set arbitrary (public) properties this way, > then you've thrown away a bunch of the free encapsulation the immutable > keyword gave you in the first place. What you get is an enforced > copy-on-write, where you can set the properties to whatever state you like, > just not using normal object passing semantics. That's very different from > what the RFC shows, which are properties which are publicly readable, but > whose state is exclusively controlled by the class (and its descendants). > > > PS The rule on this mailing list is too always reply *below* the text > you're replying to.
> -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I understand that, but I think we'll have to meet in the middle. How would you handle situation where for one little change you have to manually recreate not so trivial object with a lot of arguments ? I don't think that should be a deal breaker for this RFC but I do agree that we should try to find solution to bridge that gap and put that aside in a other rfc. -- Silvio Marijić Software Engineer 2e Systems
