Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122615
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b
Precedence: bulk
MIME-Version: 1.0
Message-ID: <0efbb5ca-0b7f-4433-8afd-0dbb9cdb326f@app.fastmail.com>
In-Reply-To: 
 <CABdc3Wr-rjDVXvc6ed4SoNe0JvJDQz=0DxxfKmRZdf85UZdCrw@mail.gmail.com>
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <a715dacb-9bac-4bea-a2bb-c623737fd81e@app.fastmail.com>
 <CABdc3WrxQx4GOgXdo9UeryXY+aFHB_+0hAjwT6z-=dS8jMet9g@mail.gmail.com>
 <84adc38a-210e-4f21-9145-0c99ae8c56f2@app.fastmail.com>
 <CABdc3Wr-rjDVXvc6ed4SoNe0JvJDQz=0DxxfKmRZdf85UZdCrw@mail.gmail.com>
Date: Mon, 11 Mar 2024 17:32:45 +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 Mon, Mar 11, 2024, at 4:58 PM, Micha=C5=82 Marcin Brzuchalski wrote:

>> Hm, interesting.  I'll have to check with Ilija on feasibility.  My q=
uestion is, how would it eliminate it?
>>=20
>> Suppose we hypothetically have a "ReflectionPropertyWithHooks" reflec=
tion object.  It has those three extra methods on it.  But that means $r=
Object->getProperty() could return a ReflectionProperty or ReflectionPro=
pertyWithHooks, and you don't know which it is.  You'd have to do an ins=
tanceof check to know which type of property it is, and thus what method=
s are available.  That doesn't seem any less clumsy (nor more, to be fai=
r) than calling isVirtual().=20
>
> It is similar when you work with ReflectionType or ReflectionEnum, you=20
> always need to match against a certain type to ensure the code will=20
> behave predictably.
>=20
>> $rProp =3D $rObject->getProperty('foo', $obj);
>> $rProp->getValue(); // works always.
>>=20
>> if (!$rProp->isVirtual()) {
>>     $rProp->getRawValue(); // Works, may or may not be the same retur=
n as getValue()
>> }
>>=20
>> vs.
>>=20
>> if (!$rProp instanceof VirtualProperty) {
>>   $rProp->getRawValue(); // Works.
>> }
>>=20
>> That doesn't seem to be an improvement.  If you omit the conditional,=
 you still need a catch one way or the other.  It just changes what gets=
 thrown (an Exception vs an Error).  What type of hierarchy were you thi=
nking of that would help here?
>
> My thinking was like:
> 1. if the property has hooks, only then calling getRawValue,=20
> setRawValue, or isVirtual make sense,
> 2. if the property has no hooks and is static calling getRawValue, or=20
> setRawValue always throws because of "On a static property, this metho=
d=20
> will always throw an error."
> 3. if the property is "virtual", calling getRawValue, or setRawValue=20
> always throws an error,
> 4. if the property is not "virtual", calling getValue, or setValue is=20
> safe and never throws, otherwise it may throw under some conditions=20
> related to certain hook presence.
>
> In conclusion, I thought that the presence of hooks introduces 3 new=20
> methods but some will always be thrown because of incorrect usage.
> Normally, I'd model it with subtypes to completely avoid try-catch=20
> blocks for the cost of a simple instanceof check which I consider much=20
> cleaner for the reader than a bunch of try-catch blocks. Remember abou=
t=20
> static analysis, each of them when checked will propose to handle=20
> possible exceptions.
>
> But as wrote before, I don't know how to model it well.

Agreed, though I don't know how to model it either. :-)  If someone can =
figure out a way to do so before we go to a vote, we'll consider it.

--Larry Garfield