Re: RFC - Immutable classes
| From: | Michał Brzuchalski | Date: | Mon, 05 Sep 2016 02:21:46 +0000 |
| Subject: | Re: RFC - Immutable classes | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95626@lists.php.net to get a copy of this message | ||
2016-09-04 22:38 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:
> On 9/4/2016 2:29 PM, Michał Brzuchalski wrote:
> >> Providing
mutator |
> >> mut keyword as method modifier sounds liek a
> good
> >> idea,
> >> althought passing $clone parameter as first additional
> >> param could
> break
> >> method declaration and would be misleading.
> >>
> >> Assuming mutator method is designed to return mutated clone of
> immutable
> >> object
> >> having $clone variable could be handled internally
> >> without breaking
> >> method declaration.
> >>
> >> Such variable could be unlocked while in mutator method and locked on
> >> return.
> >> I was thinking about additional check if such mutator returns
> >> $clone
> but
> >> not $this
> >> but I don't see the need of it - assuming there is no what to change in
> >> some
> >> circumstances ther would be also possible to return
> >> $this.
> >>
> >> The return type declaration self could increase
> >> readability, but
> should
> >> not be required,
> >> as some developers doesn't already use return types.
> >>
> >
> > It could look like in this gist
> > „†*sò
> > Ô{z•`†VShttps://gist.github.com/brzuchal/e7b721e22a19cca42ec0d1f597a23baf
> >
>
> This is exactly how I meant it, yes. I actually prefer it if the
> variable just exist in the context instead of passing it as first
> argument. It's less obvious that it exists but the same could be said
> about $this.
>
> Would it be possible to have this thing just in time instead of
> automatically created in every mutator function?
>
> public mutator function f() {
> if (condition) {
> $clone is created;
> return $clone;
> }
> return $this;
> }
>
> PS: I started overhauling the test cases and error messages and will
> create a PR against your branch soon. I will start with the RFC
> afterwards. Should I simply edit the RFC in the Wiki or should we manage
> this somewhere else?
>
>
You may begin with modifications on RFC eg. in a gist so we can all discuss
about it before putting on RFC, is that okay to you?
> --
> Richard "Fleshgrinder" Fussenegger
>
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
brzuchalski.com