Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110956
MIME-Version: 1.0
In-Reply-To: <1e39fdcb-16d2-42c3-95cf-507f7b647b50@www.fastmail.com>
References: <CAJpLVh3VjCV4kR4n2EGnfYx8J6zQ7FafG7Q6kdbQ0HEMxZHMmw@mail.gmail.com>
 <1e39fdcb-16d2-42c3-95cf-507f7b647b50@www.fastmail.com>
Date: Sat, 11 Jul 2020 21:04:34 +0000
Message-ID: <CAJpLVh1fyQNPnAPP9SVJ+T4XAGJe95-OYp=w8PsK77zSVr+Qww@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 19:08 GMT, Larry Garfield <larry@garfieldtech.com>:
> On Sat, Jul 11, 2020, at 9:06 AM, Olle H=C3=A4rstedt wrote:
>> Dear internals,
>>
>> 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.
>>
>> Use-case: Mutable objects that cannot be shared (without (deep) cloning)=
.
>>
>> Rational: Immutable objects are considered "easier to reason about"
>> and generally more safe, and as a way to avoid
>> spooky-action-at-a-distance. I argue that mutability is totally fine
>> as long as it's not *being shared*. Currently, there's no way to
>> enforce this in PHP, *but* PHP has a refcounting GC which could do
>> this. This would be a more performant alternative than to build lots
>> of immutable objects using $obj->whereSomething('bla') constructs.
>>
>> Cons: If PHP switches to tracing GC, it will be unusable.
>>
>> What do you think? Should I write it down as an RFC? Implementation
>> should be straight-forward, assuming refcount is manipulated at a
>> single place in the source.
>>
>> Regards
>> Olle
>
> I like the goal of addressing shared mutable state is a laudable one and =
I
> think most here share it.  However, I think uniqueness checking is the wr=
ong
> approach, for reasons others have already explained.
>
> You're correct that the thing to avoid is shared mutable state.  That can=
 be
> avoided either by getting rid of mutable state or shared state.  Either
> would work.  (Channeling Kevlin Henny here.)
>
> In the case of PHP, since we don't have threads to worry about the main
> source of shared state is reference variables, or refrence-esque objects.
> (Or globals, but I'm assuming most here know to avoid those already.)  Th=
at
> is, mutability or shared-ness within a function is, meh, who cares.  It's=
 at
> function boundaries that we care.
>
> As others noted, a ref count check wouldn't help with that much, because =
the
> act of passing an object to another function necessarily increases the
> refcount, thus eliminating the main benefit.
>
> Rather, the way to eliminate shared-ness is to have "structs," that is,
> objects that pass by value-ish rather than pass-by-reference-ish.  (Yes i=
t's
> more complicated than that, I know, I'm talking about the user-space
> implications.)  PHP 4 objects all worked that way, which was a problem fo=
r
> anything with services our resources behind it.  That's why it changed in
> PHP 5 to the more common by-ref-ish behavior, which... is a problem for
> value objects.
>
> Both use cases are valid.  It's why newer languages like Go and Rust take=
 a
> completely different approach to what "object" even means in the first
> place.
>
> It's been discussed before but never really implemented; I do think the w=
ay
> to help break the "shared state" side is to allow objects to get flagged =
as
> "will use by-value passing" or "will use by-reference passing" (again,
> implications, not implementation).  That is, if you have a by-val object =
and
> pass it to a function, it behaves the same way as passing a string or an
> array: Copy-on-write of the object when any changes are made to propertie=
s
> of the object.  Probably we'd also need to require that properties of by-=
val
> objects cannot be by-ref objects or resources, which seems reasonable to
> me.
>
> I think that would do a far better job of addressing the
> shared-mutable-state issue than reference counting, because it attacks th=
e
> 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