Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122610
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: <84adc38a-210e-4f21-9145-0c99ae8c56f2@app.fastmail.com>
In-Reply-To: 
 <CABdc3WrxQx4GOgXdo9UeryXY+aFHB_+0hAjwT6z-=dS8jMet9g@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>
Date: Mon, 11 Mar 2024 14:27:34 +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 8:35 AM, Micha=C5=82 Marcin Brzuchalski wrote:
> Hi Larry,
>
> pt., 8 mar 2024 o 16:55 Larry Garfield <larry@garfieldtech.com> napisa=
=C5=82(a):
>> Hi folks.  Based on earlier discussions, we've made a number of chang=
es to the RFC that should address some of the concerns people raised.  W=
e also had some very fruitful discussions off-list with several develope=
rs from the Foundation, which led to what we feel are some solid improve=
ments.
>>=20
>> https://wiki.php.net/rfc/property-hooks
>>=20
>
> This RFC looks awesome, thanks Larry and Ilija I love the functionalit=
y=20
> in its current shape.
>
>> Thank you everyone for the feedback so far, and if you still have som=
e, please say so.  (Even if it's just to say that you're happy with the =
RFC now so we feel more comfortable bringing it to a vote.)
>
> The only thing I don't like and can still be worked on is the=20
> reflection mechanism changes.
> The proposed methods isVirtual and getRawValue, setRawValue pair=20
> introduces a need to catch exceptions which could be eliminated by=20
> subtyping ReflectionProperty.
> Having these methods on a separate subtype allows returning a valid=20
> value.
> I realize this isn't trivial because for the last 2 days, I was=20
> thinking about giving it a name and TBH cannot figure out anything=20
> feasible.
> If this is not possible to put in understandable words then at least=20
> mention it in FAQ and why not.
>
> Cheers,
> Micha=C5=82 Marcin Brzuchalski

Hm, interesting.  I'll have to check with Ilija on feasibility.  My ques=
tion is, how would it eliminate it?

Suppose we hypothetically have a "ReflectionPropertyWithHooks" reflectio=
n object.  It has those three extra methods on it.  But that means $rObj=
ect->getProperty() could return a ReflectionProperty or ReflectionProper=
tyWithHooks, and you don't know which it is.  You'd have to do an instan=
ceof check to know which type of property it is, and thus what methods a=
re available.  That doesn't seem any less clumsy (nor more, to be fair) =
than calling isVirtual(). =20

$rProp =3D $rObject->getProperty('foo', $obj);
$rProp->getValue(); // works always.

if (!$rProp->isVirtual()) {
    $rProp->getRawValue(); // Works, may or may not be the same return a=
s getValue()
}

vs.

if (!$rProp instanceof VirtualProperty) {
  $rProp->getRawValue(); // Works.
}

That doesn't seem to be an improvement.  If you omit the conditional, yo=
u still need a catch one way or the other.  It just changes what gets th=
rown (an Exception vs an Error).  What type of hierarchy were you thinki=
ng of that would help here?

--Larry Garfield