Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110950
MIME-Version: 1.0
In-Reply-To: <E267A687-CF67-4973-9ECE-86F230F9F735@gmail.com>
References: <CAJpLVh3VjCV4kR4n2EGnfYx8J6zQ7FafG7Q6kdbQ0HEMxZHMmw@mail.gmail.com>
 <6D442090-FA51-48A9-A07D-F27F5EF6FC0A@gmail.com> <CAJpLVh0LHO3yWtqUTwGh8XhZqzwi2JRt8R34k8nRY3qwKQ=Qog@mail.gmail.com>
 <E267A687-CF67-4973-9ECE-86F230F9F735@gmail.com>
Date: Sat, 11 Jul 2020 17:10:43 +0000
Message-ID: <CAJpLVh2PPfYs7h59_grD5RhA4ohD+Nmfgh6DAV=3sJu4ZGLccw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: 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 16:50 GMT, Rowan Tommins <rowan.collins@gmail.com>:
> On 11 July 2020 16:13:24 BST, "Olle H=C3=A4rstedt" <olleharstedt@gmail.co=
m>
> wrote:
>>Yes, the point is to be limiting. :) Just like with immutability, you
>>apply certain limitations to avoid access abuse.
>
>
> Taken to extremes, this is the "secure a server by encasing it in concret=
e"
> strategy - the hard part about designing useful limitations is not the pa=
rts
> you want to make impossible, it's the parts you want to remain easy.
>
> There is a reason Rust has a whole set of mechanisms for managing ownersh=
ip,
> not just a single "mine/yours" split, because they allow the programmer t=
o
> express what they want to do with the object.
>
>
>>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
>
>
> The difference in my mind between freezing an object and tracking ownersh=
ip
> is that "frozen/unfrozen" would be an explicit state set on the object, n=
ot
> a measurement that differs as it is used. So either the user says "freeze
> $object", and it is then immutable for the rest of the program, or some
> point after construction implicitly freezes it with the same effect.
>
> This eliminates the dependence on tracking ownership or giving meaning to
> the refcount, because no matter how you received the object, you must no
> longer cause it to be mutated.
>
> It also has much lower performance impact. Even the automatic form can
> probably be performed by the compiler - e.g. if "new" was called in this
> function, insert a call to "freeze" before the first time the object appe=
ars
> as a function parameter
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


OK, but then there's no need for any compiler changes - just make
trait CanBeFrozenTrait, add a property $isFrozen : bool, and then make
sure all methods check this property and throw an exception if it's
violated.