Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110960
Date: Sun, 12 Jul 2020 00:24:15 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAJpLVh0nD87Gu57bPrC51TVyAXhKkEwofkK03SwGQcrP8aEpPQ@mail.gmail.com>
References: <CAJpLVh3VjCV4kR4n2EGnfYx8J6zQ7FafG7Q6kdbQ0HEMxZHMmw@mail.gmail.com> <1e39fdcb-16d2-42c3-95cf-507f7b647b50@www.fastmail.com> <CAJpLVh1fyQNPnAPP9SVJ+T4XAGJe95-OYp=w8PsK77zSVr+Qww@mail.gmail.com> <3bfb89c5-c8fd-4587-8c1f-8b7bbbaca692@www.fastmail.com> <CAJpLVh0nD87Gu57bPrC51TVyAXhKkEwofkK03SwGQcrP8aEpPQ@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: <C9C198A4-5829-41E2-A14A-548FFDD9AD97@gmail.com>
Subject: Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at refcount > 1
From: rowan.collins@gmail.com (Rowan Tommins)

On 11 July 2020 22:47:21 BST, "Olle H=C3=A4rstedt" <olleharstedt@gmail=2Eco=
m> wrote:
>You're misunderstanding=2E :) Yes, it should be shared, but not with the
>same access level as the owner=2E If a dependent class closes the
>connection it will cause spooky-action-at-a-distance somewhere else in
>the program=2E=20


I think that particular example is solved adequately by destructors: if yo=
u know you hold the last reference to an object, you can unset() that refer=
ence and the destructor will fire=2E

You'd only need the ability to "unfreeze" an object if you were going to m=
utate it and then carry on using it=2E


> Sorry, it's related to refcount as ownership checking=20


I still don't think those concepts map well=2E If you store two references=
 to an object in an array, and then unset one of them at random, does it ma=
ke sense to say the remaining reference "owns" that value, because the obje=
ct now has a refcount of one?

As I understand it, ownership in Rust implies not just the *right* to free=
 something, but the *obligation* to do so=2E That only works if ownership i=
s explicitly assigned, rather than being a side effect of other references =
being released=2E


Thinking about destructors, a better description of how PHP currently work=
s might be that the owner of an object is the object itself, and the refcou=
nt is a count of how many times it has been borrowed=2E So once the constru=
ctor completes, all we can say is that there is at least one "borrowed" ref=
erence somewhere in the code; once that stops being true, the "owner" is no=
tified, and runs the code in the destructor=2E


You could create a wrapper object and have a way to check that its destruc=
tor had been called - anything from setting a global variable to holding a =
WeakRef and calling its valid() method - but if something *does* hold onto =
a reference, there's not much you can do about it=2E=20

I can't think of a scenario where the code that wants to "own" the object =
wouldn't end up equivalent to either full immutability (don't mutate it aft=
er initialisation because you can't guarantee yours is the only reference) =
or an optimised copy-on-write (mutate if you happen to have the last refere=
nce, otherwise clone)=2E It would be better for the language to implement t=
hose in a user-friendly way than exposing the implementation details of ref=
counting=2E

Regards,


--=20
Rowan Tommins
[IMSoP]