Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127894
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 05 Jul 2025 00:57:50 +0200
To: internals@lists.php.net
Message-ID: <96e5addb-1570-4b4f-9915-c3fc55988f24@app.fastmail.com>
In-Reply-To: 
 <CALaXqqSPwzfvnNs=xyenP9+KJ9wC5p4nBXdmzjCezpMpzoFCYg@mail.gmail.com>
References: 
 <CALaXqqRKy4_y3HkO6dVhVcOjoHOp=HYdsU7v3SVZQ8kr1EfgLA@mail.gmail.com>
 <CALaXqqSPwzfvnNs=xyenP9+KJ9wC5p4nBXdmzjCezpMpzoFCYg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute
Content-Type: multipart/alternative;
 boundary=b3ca75ad1104462784f9cf737fd30866
From: rob@bottled.codes ("Rob Landers")

--b3ca75ad1104462784f9cf737fd30866
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Sun, Jun 22, 2025, at 22:00, Daniel Scherzer wrote:
> On Tue, Jun 17, 2025 at 4:26=E2=80=AFPM Daniel Scherzer <daniel.e.sche=
rzer@gmail.com> wrote:
>> Hi internals,
>>=20
>> I'd like to start the discussion for a new RFC about adding a `#[\Del=
ayedTargetValidation]` attribute.
>>=20
>> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
>> * Implementation: https://github.com/php/php-src/pull/18817
>>=20
>> --Daniel
>=20
>=20
> It seems a common point of discussion is the difference in behavior be=
tween internal and userland attributes, so I wanted to clarify a few thi=
ngs:
>=20
> * Userland attributes are always metadata, in part because of the back=
wards and forward compatibility that those attributes provide - the attr=
ibute does not need to exist in order to be used, it just needs to exist=
 (and target the location) when you call ReflectionAttribute::newInstanc=
e() to instantiate
> * Internal attributes are a mix between metadata and a way to plug int=
o the engine. There were already existing ways to plug into the engine (=
e.g. using magic methods or implementing the Countable or ArrayAccess in=
terfaces) but attributes provided a way to plug into the engine when you=
 don't just want to add a function override, but rather something else (=
like indicating a parameter should be redacted in backtraces with `#[\Se=
nsitiveParameter]`). It would probably be impossible to do that securely=
 with a userland attribute and userland error handler that manually reda=
cted things...
> * Attributes were designed to have good compatibility - the syntax cho=
sen for PHP 8.0 was, in prior versions of PHP, used for comments - so an=
y code with attributes could also work in PHP 7.4, just without the meta=
data. Similarly, by not validating userland attributes until they are ac=
cessed with reflection, you can add an attribute that does not exist yet=
 (e.g. if using different versions of a library) with minimal complicati=
ons.
> * Internal attributes are validated at compile time - because they can=
 be. Internal attributes tell the engine to do something, and it makes s=
ense (at least to me) that if the engine cannot do that thing, there sho=
uld be an error without needing to wait for ReflectionAttribute::newInst=
ance() to be called.
>=20
> But, the validation of internal attributes at compile time means that =
they lose the compatibility features of userland attributes, and that is=
 what this RFC is trying to address. To be clear, I think the difference=
 in behavior between userland and internal attributes is a) fundamentall=
y based on the difference in capabilities (pure metadata vs engine behav=
ior) and b) something that should not be changed without significant fur=
ther investigation.

I don=E2=80=99t think this is quite right. Because non-existent attribut=
es can be used, if you use attributes in your library, you already know =
to only ever, and I mean only ever, instantiate your own attributes. Att=
empting to instantiate someone else=E2=80=99s attributes can result in c=
rashes. This means any delayed attributes will most likely never be vali=
dated by anything.

>=20
> This new `#[\DelayedTargetValidation]` is meant to simplify things, an=
d to partially unify the behavior of the errors - if you are getting any=
 errors from internal attributes and want to suppress them at compile ti=
me, just add the new attribute everywhere.
>=20
> -Daniel=20

I don=E2=80=99t think this is =E2=80=9Cforward compatibility=E2=80=9D, t=
his is completely disabling the attribute.

=E2=80=94 Rob
--b3ca75ad1104462784f9cf737fd30866
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv>On Sun, Jun 22, 2025, at 22:00, Daniel Scherzer wrote:</div><blockquo=
te type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr">=
On Tue, Jun 17, 2025 at 4:26=E2=80=AFPM Daniel Scherzer &lt;<a href=3D"m=
ailto:daniel.e.scherzer@gmail.com">daniel.e.scherzer@gmail.com</a>&gt; w=
rote:</div><div class=3D"qt-gmail_quote qt-gmail_quote_container"><block=
quote class=3D"qt-gmail_quote" style=3D"margin-top:0px;margin-right:0px;=
margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div d=
ir=3D"ltr"><div>Hi internals,</div><div><br></div><div>I'd like to start=
 the discussion for a new RFC about adding a `#[\DelayedTargetValidation=
]` attribute.</div><div><br></div><div>* RFC:&nbsp;<a href=3D"https://wi=
ki.php.net/rfc/delayedtargetvalidation_attribute" target=3D"_blank">http=
s://wiki.php.net/rfc/delayedtargetvalidation_attribute</a></div><div>* I=
mplementation:&nbsp;<a href=3D"https://github.com/php/php-src/pull/18817=
" target=3D"_blank">https://github.com/php/php-src/pull/18817</a></div><=
div><br></div><div>--Daniel</div></div></blockquote><div><br></div><div>=
<br></div><div>It seems a common point of discussion is the difference i=
n behavior between internal and userland attributes, so I wanted to clar=
ify a few things:</div><div><br></div><div>* Userland attributes are alw=
ays metadata, in part because of the backwards and forward compatibility=
&nbsp;that those attributes provide - the attribute&nbsp;does not need t=
o exist in order to be used, it just needs to exist (and target the loca=
tion) when you call ReflectionAttribute::newInstance() to instantiate</d=
iv><div>* Internal attributes are a mix between metadata and a way to pl=
ug into the engine. There were already existing ways to plug into the en=
gine (e.g. using magic methods or implementing the Countable or ArrayAcc=
ess interfaces) but attributes provided a way to plug into the engine wh=
en you don't just want to add a function override, but rather something =
else (like indicating a parameter should be redacted in backtraces with =
`#[\SensitiveParameter]`). It would probably be impossible to do that se=
curely with a userland attribute and userland error handler that manuall=
y redacted things...</div><div>* Attributes were designed to have good c=
ompatibility - the syntax chosen for PHP 8.0 was, in prior versions of P=
HP, used for comments - so any code with attributes could also work in P=
HP 7.4, just without the metadata. Similarly, by not validating userland=
 attributes until they are accessed with reflection, you can add an attr=
ibute that does not exist yet (e.g. if using different versions of a lib=
rary) with minimal complications.</div><div>* Internal attributes are va=
lidated at compile time - because they can be. Internal attributes tell =
the engine to do something, and it makes sense (at least to me) that if =
the engine cannot do that thing, there should be an error without needin=
g to wait for ReflectionAttribute::newInstance() to be called.</div><div=
><br></div><div>But, the validation of internal attributes at compile ti=
me means that they lose the compatibility features of userland attribute=
s, and that is what this RFC is trying to address. To be clear, I think =
the difference in behavior between userland and internal attributes is a=
) fundamentally based on the difference in capabilities (pure metadata v=
s engine behavior) and b) something that should not be changed without s=
ignificant further investigation.</div></div></div></blockquote><div><br=
></div><div>I don=E2=80=99t think this is quite right. Because non-exist=
ent attributes can be used, if you use attributes in your library, you a=
lready know to only ever, and I mean only ever, instantiate your own att=
ributes. Attempting to instantiate someone else=E2=80=99s attributes can=
 result in crashes. This means any delayed attributes will most likely n=
ever be validated by anything.</div><div><br></div><blockquote type=3D"c=
ite" id=3D"qt" style=3D""><div dir=3D"ltr"><div class=3D"qt-gmail_quote =
qt-gmail_quote_container"><div><br></div><div>This new `#[\DelayedTarget=
Validation]` is meant to simplify things, and to partially unify the beh=
avior of the errors - if you are getting any errors from internal attrib=
utes and want to suppress them at compile time, just add the new attribu=
te everywhere.</div><div><br></div><div>-Daniel&nbsp;</div></div></div><=
/blockquote><div><br></div><div>I don=E2=80=99t think this is =E2=80=9Cf=
orward compatibility=E2=80=9D, this is completely disabling the attribut=
e.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></bod=
y></html>
--b3ca75ad1104462784f9cf737fd30866--