Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110944
Date: Sat, 11 Jul 2020 15:56:29 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAJpLVh3VjCV4kR4n2EGnfYx8J6zQ7FafG7Q6kdbQ0HEMxZHMmw@mail.gmail.com>
References: <CAJpLVh3VjCV4kR4n2EGnfYx8J6zQ7FafG7Q6kdbQ0HEMxZHMmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <6D442090-FA51-48A9-A07D-F27F5EF6FC0A@gmail.com>
Subject: Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at refcount > 1
From: rowan.collins@gmail.com (Rowan Tommins)

Hi Olle,

On 11 July 2020 15:06:13 BST, "Olle H=C3=A4rstedt" <olleharstedt@gmail=2Ec=
om> wrote:
>I'd like to discuss the concept of ownership in PHP, from the point of
>view of a new interface UniqueInterface (or SplUniqueInterface or
>something), which will throw a UniqueException if refcount > 1=2E

It's an intriguing idea, but I'm not sure how well it would work in practi=
ce=2E Maintaining a strict refcount of one means never passing the value to=
 another function or scope, which seems very limiting=2E=20

It would also run into the usual problem PHP has that everything is determ=
ined at run-time, so every time you pass an object anywhere, the engine wou=
ld need to check it wasn't marked in this way=2E That could be avoided if i=
nstead of a special type of value, this was a special type of variable; the=
n it could probably be determined at compile time that you were passing a "=
local only" variable to another scope=2E


>Use-case: Mutable objects that cannot be shared (without (deep)
>cloning)=2E

This is another tricky aspect - like enforcing deep immutability, it impli=
es some recursive constraints which are easy to enforce for scalars, but tr=
icky once you look at things like arrays, which can contain references, obj=
ects, other arrays, etc=2E


As described, the user would have to manually perform a clone whenever the=
 object was passed anywhere, even if they weren't mutating it anywhere=2E I=
f you let the language do that automatically, you can use an automatic copy=
-on-write system, like PHP already does for arrays (and, funnily enough, PH=
P 4 did for objects)=2E

Alternatively, you can make the object purely immutable once it has passed=
 out of its initial scope, or once a special function has been called to "f=
reeze" it=2E This would be an interesting solution to the "modified clone" =
problem of full immutability (how to implement withFoo methods), since any =
"frozen" object could be cloned to get a mutable copy, which would be froze=
n before passing on=2E

Regards,


--=20
Rowan Tommins
[IMSoP]