Re: RFC - Immutable classes
| From: | Michał Brzuchalski | Date: | Mon, 05 Sep 2016 08:26:03 +0000 |
| Subject: | Re: RFC - Immutable classes | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95633@lists.php.net to get a copy of this message | ||
I had a talk at Room11 and we discussed idea of
mutator keyword.
There were some concerns using mutator as a keyword - that's because
immutable object is not being muted and also magically appeared $clone
would be confusing. There's an idea of creating clone before function begins
and operating simply on $this while it's newly created clone from
immutable
object instance and the additional keyword for such method would be for eg.
transformer, so basically it may look like this:
immutable class Money {
public $amount = 0;
public $currency;
public function __construct($amount, $currency) {
$this->amount = $amount;
$this->currency = $currency;
}
public transformer function amount($newamount) {
$this->amount = $newAmount; // $this actually is newly created clone
return $this;
}
}
$oneHundret = new Money(100, $eur);
$twoHundret = $oneHundret->amount(200);
How about that?
2016-09-05 4:21 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>:
>
>
> 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
>> >
>> > https://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
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
brzuchalski.com