Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112696
To: internals@lists.php.net
References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com>
 <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin>
 <CAJpLVh2M3iKhG8b2qZydf_70K4NYdZ5fpSEsRNK7uLeESUPHKg@mail.gmail.com>
 <459d7ff7-e553-dce9-7d43-c3b1e772e572@gmail.com>
 <CAJpLVh31UzSJvKdypQ=Mh+6CLvfUCrF==z6HBDD1_nuYqFzG5A@mail.gmail.com>
 <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com>
 <C9E7D7C8-2EB8-479A-B0BF-E992172765EE@newclarity.net>
Message-ID: <30906866-1971-8395-05a0-fd78d054bb89@gmail.com>
Date: Thu, 31 Dec 2020 12:37:29 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <C9E7D7C8-2EB8-479A-B0BF-E992172765EE@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Analysis of property visibility, immutability, and
 cloning proposals
From: rowan.collins@gmail.com (Rowan Tommins)

Hi Mike and Olle,


On 31/12/2020 00:24, Mike Schinkel wrote:
> A different perspective is that "withX" methods require a mental translation where "addX" methods do not, much like how a person whose native language is English will find it a challenge to (or cannot) "think" in French.


I wonder if that's just about the choice of names, rather than the 
mutability/immutability itself?


>> $start = MyDate::today();
>> $end = $start->withAddedDays(5);
>>
>> vs
>>
>> $start = MyDate::today();
>> $end = clone $start;
>> $end->addDays(5);
> Ignoring that you are comparing apples and oranges (scalars to objects,) the latter is easier to reason about IMO.


Ignoring the distinction between "scalar" and "object" was kind of the 
point: they are both "values", and are more naturally treated the same 
as differently.


To take a different example, consider writing a new number type (for 
arbitrary precision, or complex numbers, or whatever), with an "add" method.

The mutable version looks something like this:

public function add($other) {
     $this->value = $this->value + $other;
}

and has to be used like this:

$start = new MyNumber(1);
$end = clone $start;
$end->add(5);


The immutable version might look more like this:

public function add($other) {
     return clone $this with { value: $this->value + $other };
}

and is used like this:

$start = new MyNumber(1);
$end = $start->add(5);

That's much closer to the "$end = $start + 5;" we're used to.


On 30/12/2020 18:42, Olle Härstedt wrote:
>> To put it a different way, value types naturally form*expressions*,
>> which mutable objects model clumsily. It would be very tedious if we had
>> to avoid accidentally mutating the speed of light:
>>
>> $e = (clone $m) * ((clone $c) ** 2);
> Using a variable on right-hand side does not automatically create an
> alias, so in the above case you don't have to use clone.


Whether or not the type system forced you to, you'd have to use clone if 
the values were implemented as mutable. Switching to methods again may 
make that clearer:

$c = new MyNumber(299_792_458);
$m = new MyNumber(10);
$e = $m->multiply( $c->square() );

If multiply() and square() are mutating state, rather than returning new 
instances, $c is now 89875517873681764, which is going to totally mess 
up the universe...


Regards,

-- 
Rowan Tommins
[IMSoP]