Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112650
To: internals@lists.php.net
References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com>
 <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin>
 <ea3ad019-22be-4a1a-8153-1e56b66e4389@www.fastmail.com>
 <CAJpLVh1ARny-tESsAD00piBPN19+yKEvianYMTjwgktF0gyvag@mail.gmail.com>
Message-ID: <e64cf2a9-a766-9349-7829-7d2109271932@gmail.com>
Date: Tue, 29 Dec 2020 22:43:18 +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: <CAJpLVh1ARny-tESsAD00piBPN19+yKEvianYMTjwgktF0gyvag@mail.gmail.com>
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)

On 29/12/2020 18:38, Olle Härstedt wrote:
> Instead of shoe-horning everything into the PHP object system, did
> anyone consider adding support for records instead, which would always
> be immutable, and could support the spread operator for cloning-with
> similar as in JavaScript or OCaml? They could be based on PHP arrays
> and thus be passed by value.


While we could create a brand new "record" or "struct" type, I think 
there are a few reasons to think it would end up *looking* more like 
objects than arrays:

- we have an established syntax for declaring types of object (class Foo 
{...}), and none for declaring types of array
- the 'bar' in $foo['bar'] is an expression, implying dynamic options; 
the bar in $foo->bar is a bare identifier, implying statically defined 
options
- similarly, we have a syntax for creating object instances, with 
statically analysable members: new Foo(bar: 42)


The spread operator could be made to work with either style, if we 
preferred it to using "clone ... with ...":

- ['bar'=>69, ...$existingFoo]
- new Foo(bar: 69, ...$existingFoo)


However, arrays arguably already have a clone-with syntax, more normally 
thought of as "copy-on-write". Rather than "mutable with special logic 
to pass and assign by value", I think you can model their behaviour as 
"immutable with special logic to clone with modifications":

$foo = ['bar'=>42, 'baz'=>101];
$newFoo = $foo; // lazy assignment by value is indistinguishable from 
assignment by pointer
$newFoo['bar'] = 69; // $newFoo is a modified clone of $foo
$newFoo['bar'] = 72; // mutating $newFoo in place is indistinguishable 
from creating and assigning another modified clone


In theory, "records" could have this ability with object-like syntax:

$foo = new Foo(bar: 42, baz: 101);
$newFoo = $foo;
$newFoo->bar = 69; // $newFoo is a modified clone
$newFoo->bar = 72; // can be optimised as in-place modification, but 
conceptually cloning again


In the simple case, that's equivalent to a clone-with:

$foo = new Foo(bar: 42, baz: 101);
$newFoo = clone $foo with { bar: 69 };
$newFoo = clone $newFoo with { bar: 72 }; // can probably be optimised 
the same way as the above examples


It would allow more complex modifications, though, such as deep 
modification:

$foo = new Foo(bar: new Bar(name: 'Bob'));
$newFoo = $foo;
$newFoo->bar->name = 'Robert';

That last line would do the same as this:

$newFoo = clone $newFoo with { bar: clone $newFoo->bar with { name: 
'Robert' }};

How desirable that is, and how it fits with the use cases in Larry's 
post, I'm not sure.


Regards,

-- 
Rowan Tommins
[IMSoP]