Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111958
User-Agent: Cyrus-JMAP/3.3.0-355-g3ece53b-fm-20200922.004-g3ece53b9
Mime-Version: 1.0
Message-ID: <fe377540-b237-404c-8bfc-aaca9de57baa@www.fastmail.com>
In-Reply-To: 
 <CAEPJdu=dZPQbeCktySON=yVCpMgURqu7xkEM_PEZVDt=oqVVZQ@mail.gmail.com>
References: 
 <CAF+90c8w3Aw9gbdFYV+Qm7Gyo0187GUMS2PmuUzVkW78JQ_Q_w@mail.gmail.com>
 <CAEPJdunXkRw7UVrg=sm=dSSJ_Fd5VnBsd0oW9MGfK4NNGDyBTQ@mail.gmail.com>
 <CAG9XoMTtLcQ6jS_fCqNsL41q48zDvvfMZZjbwvRvOT5MJmCzAQ@mail.gmail.com>
 <CAEPJdunAjvfZgV52XHoaQJDzXz12K4m0suoqGdFitCT7QR7XAA@mail.gmail.com>
 <CAOWwgpn457VLk1gOgqXUXZ8OP=pMqF7YW4FG-oM5yZ=RvFpu5A@mail.gmail.com>
 <CAG9XoMT+psKRLSUo070dNouQkeWBEXSLU=5c38L6Cnii4rNsnQ@mail.gmail.com>
 <CAEPJdu=dZPQbeCktySON=yVCpMgURqu7xkEM_PEZVDt=oqVVZQ@mail.gmail.com>
Date: Tue, 29 Sep 2020 08:45:12 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Attributes and constructor property promotion
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Sep 28, 2020, at 12:06 PM, Benjamin Eberlei wrote:
> On Mon, Sep 28, 2020 at 4:35 PM Benjamin Morel <benjamin.morel@gmail.c=
om>
> wrote:
>=20
> > On Mon, 28 Sep 2020 at 15:17, Nicolas Grekas <nicolas.grekas+php@gma=
il.com>
> > wrote:
> >
> >> I assume the 80% case is properties, because attributes did not hav=
e
> >>> docblock annotations yet, that means this use-case isn't even poss=
ible at
> >>> the moment. Yet annotations on properties are widespread (Doctrine=
 ORM,
> >>> symfony validator, ...).
> >>>
> >>
> >> I'm 100% with Benjamin here, this is what will be the most useful t=
o me
> >> also.
> >>
> >
> > To be clear, I don't have a strong opinion against yours, I'm just
> > pointing out the fact that even though it might be useful, it might =
also be
> > confusing and create yet another WTF moment in PHP for developers. S=
ure, it
> > might make more sense to apply to the property. Sure, so far annotat=
ions
> > weren't possible on parameters. But is that obvious to the average
> > developer writing the attribute? A few years down the road, DI conta=
iners
> > may have broad support for annotating parameters for injection. Will=
 it
> > still be obvious then that an attribute on a promoted property appli=
es to
> > the property only?
> >
> > I do agree that applying the attribute to both the property and the
> > parameter will probably never be useful, though. So, throwing an exc=
eption
> > and forcing the de-sugaring feels like the most sensible thing to do=
 for me
> > in this case!
> >
>=20
> I haven't checked if this is possible in the code doing the "desugerin=
g",
> but what if we had an attribute on the constructor that could specify =
where
> the attributes should apply to?
>=20
> #[AttributePromotion(Attribute::TARGET_PROPERTY)]
> public function __construct(#[Foo] public string $bar) {}
>=20
> Then we could apply it to both by default, which is what is probably t=
he
> expected approach, and users could change it to apply only to properti=
es,
> which is what is the use-case that makes most sense.
>=20
> >
> > =E2=80=94 Benjamin

From a user experience POV, I'd almost expect the opposite.

If I mark the attribute as being for properties, it gets applied to the =
property.

If I mark the attribute as being for parameters, it gets applied to the =
parameter.

If I mark it for both, or don't restrict it at all, it applies to both.

That may not be how the logic is currently implemented but that's what a=
s a user I'd find least-surprising.

--Larry Garfield