Possible RFC: UniqueInterface that throws exception at refcount > 1

Hi Olle Härstedt,

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.

It'd seem like it would cause a lot of places where UniqueException could be thrown unexpectedly.
Additionally, inspecting the stack trace of an exception would also increment the refcount,
causing yet another exception.

<?php
class UniqueObject{}
function test(UniqueObject $x) {
    // ...
    // handle some edge case

    // $trace includes an array with a reference to $x at $trace[0]['args'][0],
    // increasing the refcount to 2, throwing.
    //
    // Error handlers and issue handlers would also have this issues,
    // as well as Throwable->getTrace()
    $trace = `debug_backtrace()`;
    var_dump($trace);
}
test(new UniqueObject());

Implementation should be straight-forward, assuming refcount is manipulated at a
single place in the source.

This would also introduce some performance overhead if every function that incremented the reference count of a value
now had to check if objects implemented that interface. I'd assume it would be significant.

This is something that makes more sense in compiled languages like rust that can enforce uniqueness at compile time,
and the dynamic nature of php makes that less practical.

• Tyson

Thanks for your answers!

Yes, it would be a dynamic uniqueness system, kind of.

Another more flexible alternative would be to add magic methods at
refcount = 1 and refcount > 1, possibly __owned() and __shared(int
$refcount), for classes that implement a TrackReferencesInterface or
similar. But this would need to do ~0 performance hit if not used,
don't know if possible.

Olle

2020-07-11 14:29 GMT, Chuck Adams cja987@gmail.com:

On Sat, Jul 11, 2020 at 8:06 AM Olle Härstedt olleharstedt@gmail.com
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).

I don't think you want to do this on refcount, since that would
prevent even passing it to another function or using it in any number
of expressions. What would make more sense to me would be hooking
into copy-on-write, which would also be a slightly less hot code path
than reference counting (but still a pretty critical one).

It almost sounds like a uniqueness type, something well beyond the
capabilities of PHP's type system (and most others).

--c

2020-07-11 14:56 GMT, Rowan Tommins rowan.collins@gmail.com:

Hi Olle,

On 11 July 2020 15:06:13 BST, "Olle Härstedt" olleharstedt@gmail.com
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.

It's an intriguing idea, but I'm not sure how well it would work in
practice. Maintaining a strict refcount of one means never passing the value
to another function or scope, which seems very limiting.

Yes, the point is to be limiting. :) Just like with immutability, you
apply certain limitations to avoid access abuse.

It would also run into the usual problem PHP has that everything is
determined at run-time, so every time you pass an object anywhere, the
engine would need to check it wasn't marked in this way. That could be
avoided if instead of a special type of value, this was a special type of
variable; then it could probably be determined at compile time that you were
passing a "local only" variable to another scope.

Use-case: Mutable objects that cannot be shared (without (deep)
cloning).

This is another tricky aspect - like enforcing deep immutability, it implies
some recursive constraints which are easy to enforce for scalars, but tricky
once you look at things like arrays, which can contain references, objects,
other arrays, etc.

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. If
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,
PHP 4 did for objects).

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
"freeze" it. 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 frozen
before passing on.

Regards,

--
Rowan Tommins
[IMSoP]

Regarding "freezing" an object, I actually already wrote about this in
a blog post, using dependency injection as a use-case, and a trait to
add a method to check the refcount:
http://olleharstedt.github.io/php/2020/07/08/immutable-at-borrow.html

(and, funnily enough, PHP 4 did for objects).

The funny thing about it for me is that this behavior caused me to
throw such a fit when I discovered it -- more to say burned by it --
that I swore off PHP forever at the time. Now I actually want this
behavior back, though as an opt-in. Maybe that would address some of
the intent of this proposal. It'd be easier to know with some solid
examples.
--c

2020-07-11 19:08 GMT, Larry Garfield larry@garfieldtech.com:

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 wrong
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.) That
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 it'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 for
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 way
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 properties
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 the
root problem rather than a symptom.

--Larry Garfield

--

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 = 1:

$connection = new OwnershipConnection();
$connection->open();
$ps = new PostService($connection);
$ps->updateAllPosts();  // Throws exception if $connection->close()
$connection->close();

With freeze, you could also do

$ps = 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