Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122530
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-182-gaab6630818-fm-20240222.002-gaab66308
Precedence: bulk
MIME-Version: 1.0
Message-ID: <40d811c5-43b6-4019-8428-b060ab4282d6@app.fastmail.com>
In-Reply-To: 
 <CAEPJdukJtXsnfa4dnsinQqe3O__FELsTLnWvoOo1H_T7eaNnRA@mail.gmail.com>
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <CAEPJdukJtXsnfa4dnsinQqe3O__FELsTLnWvoOo1H_T7eaNnRA@mail.gmail.com>
Date: Tue, 27 Feb 2024 23:53:07 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Feb 27, 2024, at 8:51 PM, Benjamin Au=C3=9Fenhofer wrote:

> thank you for this proposal. there are some points i'd like to make=20
> into this discussion:
>
> * Thank you for the removal of $field, it was non-idomatic from a PHP =
POV.
>
> * I would prefer that the short syntax $foo =3D> null; be voted upon=20
> separately. Personally I think it could be confusing and is too close=20
> to a regular assignment for default value and I prefer not to have it=20
> and keep the rest of the RFC.

See my long reply to Rowan just now, where I go into this.

> * The magic of detecting if a property is virtual or backed is - like=20
> Rowan said - subtle. I would also prefer this to be managed via an=20
> explicit mechanism, by for example keywording the property as=20
> "virtual", instead of the implicit way with the parsing based detectio=
n.

See my long reply to Rowan just now, where I go into this.

> * As Doctrine project maintainer, we have had some troubles supporting=20
> read only properties for proxies. I would have hoped that with hooks I=20
> can overwrite a readonly property and "hook" into it instead by=20
> defining a getter, but "no setter". From my read of the RFC this would=20
> not be allowed and throws a compile time error. Could you maybe clarif=
y=20
> why at least this special case is not possible? I didn't immediately=20
> get it from the RFC section on readonly as it only speaks about the=20
> problems in abstract.

Once again, readonly properties were designed sloppily without considera=
tion of how they would interact with other features.  Full asymmetric vi=
sibility would have been much better suited to what you describe, but th=
at was rejected.  (If hooks pass, we are considering taking a second att=
empt at aviz.  Haven't decided yet.)

As for details, consider this technically legal (if ill-advised) code:

public DateTimeImmutable $now {
  get {
    return new DateTimeImmutable();
  }
}

If that property is non-readonly, then while that may be weird, it's not=
 really unexpected.  There's no guarantee a property won't change value =
from one access to the next.  UNLESS that property is readonly.  But if =
it's readonly, what the heck does the above code do?  It would be return=
ing a different value on every request, so it violates one of the constr=
aints on readonly.  The hook can do arbitrary logic, which means there's=
 really no way for the engine to detect at compile time "wait, you're do=
ing something dynamic."  (That would be an extreme amount of work unless=
 PHP was pure-by-default, which it is not.) =20

For inheritance, this is the same reasoning for why a property cannot ha=
ve the readonly marker removed in a child class.  It breaks one of the e=
xpected constraints of the property, even if not the type per se.  (So i=
t's kinda a Liskov issue.) =20

This is true regardless of whether the property is virtual or not.  Virt=
ual properties just have the extra complication of "when you try to set =
it, there's an if (is_uninitialized()) check in the engine. What does th=
at even mean when there's no backing property??"

There's one carve out that might be supportable, which is just a set hoo=
k on a readonly property.  That MIGHT be able to work around readonly's =
flaws by making sure the set hook calls parent::$foo::set($value), to en=
sure the actual write happens in the parent (since readonly is private-s=
et, not protected-set).  Ilija tells me that could be tricky to do, howe=
ver, so we'd rather punt on that for now.  Follow-up RFCs (even this ver=
sion) could flesh out that edge case alone without impacting the rest of=
 the design.

--Larry Garfield