Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110953
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-ID: <1e39fdcb-16d2-42c3-95cf-507f7b647b50@www.fastmail.com>
In-Reply-To: 
 <CAJpLVh3VjCV4kR4n2EGnfYx8J6zQ7FafG7Q6kdbQ0HEMxZHMmw@mail.gmail.com>
References: 
 <CAJpLVh3VjCV4kR4n2EGnfYx8J6zQ7FafG7Q6kdbQ0HEMxZHMmw@mail.gmail.com>
Date: Sat, 11 Jul 2020 14:08:54 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Possible_RFC:_UniqueInterface_that_throws_except?=
 =?UTF-8?Q?ion_at_refcount_>_1?=
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jul 11, 2020, at 9:06 AM, Olle H=C3=A4rstedt wrote:
> Dear internals,
>=20
> 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.
>=20
> Use-case: Mutable objects that cannot be shared (without (deep) clonin=
g).
>=20
> 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.
>=20
> Cons: If PHP switches to tracing GC, it will be unusable.
>=20
> 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.
>=20
> 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 th=
e wrong approach, for reasons others have already explained.

You're correct that the thing to avoid is shared mutable state.  That ca=
n be avoided either by getting rid of mutable state or shared state.  Ei=
ther 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.)=
  That is, mutability or shared-ness within a function is, meh, who care=
s.  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 =
it's more complicated than that, I know, I'm talking about the user-spac=
e implications.)  PHP 4 objects all worked that way, which was a problem=
 for anything with services our resources behind it.  That's why it chan=
ged in PHP 5 to the more common by-ref-ish behavior, which... is a probl=
em for value objects.

Both use cases are valid.  It's why newer languages like Go and Rust tak=
e a completely different approach to what "object" even means in the fir=
st place.

It's been discussed before but never really implemented; I do think the =
way to help break the "shared state" side is to allow objects to get fla=
gged 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 mad=
e to properties of the object.  Probably we'd also need to require that =
properties of by-val objects cannot be by-ref objects or resources, whic=
h 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 the root problem=
 rather than a symptom.

--Larry Garfield