Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110461
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter attribute syntax
Thread-Index: AQHWOgIv0rCwDWp4oECJgOMrWx9MxKjQNb8AgABDMVCAAOWKgIAAim+/
Date: Wed, 10 Jun 2020 14:57:33 +0000
Message-ID:
 <BYAPR05MB6535A8F5D691497F461160EADE830@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CAEPJdumShcZMFSe_u0guVX2RuFf5X9FRp=i+-b62UUvaJiFipQ@mail.gmail.com>
 <BYAPR05MB653509159D9DB97A6BEC69A1DE820@BYAPR05MB6535.namprd05.prod.outlook.com>,<87fd9cef-1b54-2c8d-363b-f0d0535967e8@php.net>
In-Reply-To: <87fd9cef-1b54-2c8d-363b-f0d0535967e8@php.net>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [TX5cr5g71n0CF4Dt3bpeazK9UZ4nQ+Tl]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: d751d381-34aa-4202-5602-08d80d4e9b33
x-ms-traffictypediagnostic: BN8NAM11HT030:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 dIHn5htBIpCOvtaOEf0TcRwF4xDlE1RVauuksjwODO8XDHeNPDJ5FRY7rH+AGzarkJhVD3NC+3XUjJRo2gnmaw4jmsb2a5AI9At2iMceJuhNcdhnpB24Am/pdPWURIT41xlhjx2OIM0Oh1wj2c7HaZF6CITWjOfWSRn/G8dw4WIUE8L6GUrd/A4NSN26z4eeJHZUAuYTIy5rCl9sgT2tgg==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 fSLipamusBltgzEytKgqA/WQNporUPTFm58OJs2c8pWNL4P6szC03hcsX5KQL1SJRG12t3/DZvkUfLa+ujl9TmqJAptYgi99I+N5Z8nJCJ8tKaaGMwbxid4OjfMNVRWFBOflT+jnESU+r8TEt+KUhg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d751d381-34aa-4202-5602-08d80d4e9b33
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2020 14:57:33.4508
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM11HT030
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: theodorejb@outlook.com (Theodore Brown)

Hi Sebastian,=0A=
=0A=
On Wed, June 10, 2020 at 12:37 AM Sebastian Bergmann <sebastian@php.net> wr=
ote:=0A=
=0A=
> Am 09.06.2020 um 17:57 schrieb Theodore Brown:=0A=
> > That's an interesting argument. After thinking about it more, though,=
=0A=
> > I'm not sure I understand what the benefit would be. The docblock=0A=
> > annotation needed for PHP 7 is *already* forward compatible with PHP 8.=
=0A=
> > So wouldn't this just be duplicating the attribute and opening the=0A=
> > possibility for them to be out of sync for no benefit?=0A=
> =0A=
> This would allow the introduction of classes into PHPUnit such as=0A=
> =0A=
>      namespace PHPUnit\Attribute;=0A=
> =0A=
>      #[Attribute]=0A=
>      final class Covers=0A=
>      {=0A=
>          private string $coverageTarget;=0A=
> =0A=
>          public function __construct(string $coverageTarget)=0A=
>          {=0A=
>              $this->coverageTarget =3D $coverageTarget;=0A=
>          }=0A=
> =0A=
>          // ...=0A=
>      }=0A=
> =0A=
> that can be used to encapsulate information that may come from a ...=0A=
> =0A=
>      /**=0A=
>       * @covers \Foo\Bar\Baz=0A=
>       */=0A=
> =0A=
> ... DocBlock-style annotation in PHP 7 but may also come from an ...=0A=
> =0A=
>      #[Covers(Baz::class)]=0A=
> =0A=
> ... attribute when PHP 8 is used.=0A=
> =0A=
> This would make forward compatibility possible in code such as PHPUnit's =
=0A=
> that currently supports DocBlock-style annotations but wants to support=
=0A=
> PHP 8 attributes and to deprecate (and later remove) support for=0A=
> DocBlock-style annotations.=0A=
=0A=
So is the idea that PHPUnit 10 would still run on PHP 7.x, but would=0A=
also support native attributes for people running PHP 8? Maybe I'm=0A=
missing something, but wouldn't this be possible with the `@@` syntax=0A=
as well? The new `Covers` class would only be loaded if someone is=0A=
using attributes on PHP 8, so it's fine if it uses new PHP 8 syntax.=0A=
A parent class could be used to encapsulate coverage info for PHP 7.x.=0A=
=0A=
To me it seems like the benefit of having (single-line-only) PHP 8=0A=
attributes treated as comments in PHP 7.x is being overblown. There=0A=
is already an upgrade path for docblock annotations to attributes.=0A=
Docblocks will continue working perfectly fine in PHP 8, so projects=0A=
and libraries can wait as long as needed before migrating to the=0A=
native attribute syntax.=0A=
=0A=
Using `#[]` as the attribute syntax actually runs the risk of making=0A=
it *harder* for users to upgrade to PHP 8, since existing code that=0A=
uses hash comments starting with a left bracket would break.=0A=
=0A=
Anyway, our plan is to hold a ranked-choice vote in the RFC between=0A=
`@@`, `#[]`, and `<<>>` syntax options, so if people prefer the=0A=
tradeoffs of borrowing Rust's syntax they can vote for it.=0A=
=0A=
Best regards,  =0A=
Theodore=0A=