Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110958
MIME-Version: 1.0
In-Reply-To: <3bfb89c5-c8fd-4587-8c1f-8b7bbbaca692@www.fastmail.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>
Date: Sat, 11 Jul 2020 21:47:21 +0000
Message-ID: <CAJpLVh0nD87Gu57bPrC51TVyAXhKkEwofkK03SwGQcrP8aEpPQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at
 refcount > 1
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2020-07-11 21:25 GMT, Larry Garfield <larry@garfieldtech.com>:
> On Sat, Jul 11, 2020, at 4:04 PM, Olle H=C3=A4rstedt wrote:
>
>> > I think that would do a far better job of addressing the
>> > shared-mutable-state issue than reference counting, because it attacks
>> > the
>> > root problem rather than a symptom.
>> >
>> > --Larry Garfield
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: https://www.php.net/unsub.php
>>
>> I think freezing objects might be better fit for my imagined use-case.
>> The only problem I see is that you can't really unfreeze them. Imagine
>> a database connection that only can be open/closed at refcount =3D 1:
>>
>> ```
>> $connection =3D new OwnershipConnection();
>> $connection->open();
>> $ps =3D new PostService($connection);
>> $ps->updateAllPosts();  // Throws exception if $connection->close()
>> $connection->close();
>> ```
>>
>> With freeze, you could also do
>>
>> ```
>> $ps =3D new PostService($connection->freeze());
>> ```
>>
>> to ensure it's not closed by mistake. But then you couldn't close the
>> connection at all, except in __destruct.
>>
>> Especially, CoW for objects (at opt-in) is not a replacement where
>> ownership is supposed to replace immutability for performance reason,
>> e.g. creating a separate immutable database connection for every class
>> that uses it.
>>
>> Immutable builder are already part of PSR, e.g. here:
>> https://www.php-fig.org/psr/psr-7/
>>
>> I have to wonder how reasonable this is, when freezing or ownership
>> are also relevant solutions, with different trade-offs.
>>
>> Olle
>
> A database connection is the textbook example of an object that *should* =
be
> shared; giving a separate connection to every service object is only goin=
g
> to waste time opening multiple connections and waste open connections.
> Please don't do that.
>
> Your example seems directly contrary to the goal you're describing.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

You're misunderstanding. :) Yes, it should be shared, but not with the
same access level as the owner. If a dependent class closes the
connection it will cause spooky-action-at-a-distance somewhere else in
the program. Sorry, it's related to refcount as ownership checking and
not to throwing exception at refcount > 1. More like, "limit access at
refcount > 1" (at borrow, that is). Reference counting can be used for
both poor man's ownership semantics and to enforce non-aliasing. So
yeah, maybe I should just suggest that something like this extension
gets merged into vanilla PHP: https://github.com/qix/php_refcount
(proper way to get refcount instead of a zval dump). Or maybe make
zval dump return something instead of dumping a string.

Olle