Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111426 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 58774 invoked from network); 10 Aug 2020 14:28:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Aug 2020 14:28:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 991451804CD for ; Mon, 10 Aug 2020 06:27:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10olkn2016.outbound.protection.outlook.com [40.92.40.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 10 Aug 2020 06:27:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kxGg5ze3yDLFRzdMqqQJtduLAo5cHN+pJ7mORqb+6jMko/PLeqyLiZudUCxSZ5nnhK7udALqsZOk3fuw/CEox4sdeHhyVl6kemB8mbF+TyNyyHP8+w9YaYKvw/xdJn6IUBsV1gWdcDpkXYOjQOz52ESBMs5XBXTOojYuRjwpzxbarpeDk/hqLFIhE7WrGoHaCvh24opdFu4lWpwCQe7wUaejTMhF1vuC24dHlxC4G81l+lKEbJ0IrTOTr9YMgiNjXOO5zhuVGMC3uQf/y+t8zxnO4CMA5ZbjSP6Dd2bdB5jtwVYfJStKwGfFjYPwhSrRetNf7L1Wa/hKsgCOm2wdvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C0c8TLkhKL2688/WU3qopwMKtqUP7jJvd2aCTBpylxM=; b=KYCURGKxQATtwriO9QMHDxMN8RWdidkdTrqNEDqbqGPlAFf5Y2jtkdvy2wLjG3lldsPlRtH49zKoJV56sq2AfpNe4N+W9kevffQ931qy18FDhJ6PJtdFfPVCWJFe3Z9bV/LgOnfFRdfBCrFGi+A4FGt4Q+rGTVIJ2izVzdmes7KHpUKaWq1gZUWnIQftdVrXqGH9MTDfqNtr5l06CTT8mXKp3ZKjiKtVt8d6J5UWr3mkZ5rj9vyUSgN7bNuZhG5LVO+yc9bqxLnPQuTBv8Mxj47JBmJtPcXC+JgWn6XMrbjb0TfwIDgJyDzOzce0YCT84Z3KvXOb1WEjgfw/hgPh4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C0c8TLkhKL2688/WU3qopwMKtqUP7jJvd2aCTBpylxM=; b=fvwsr09JqnprAatpzyDbZTH/fauY5sH5sj1FEHc6zdvk1KoG1FJQkJlSuBsW1nKKjaddqmkAzZ2QxOpx7uOAHvc9wqLmFvsnYbh2mCid8Fe9wn+IrNCvfXi6jK5kc4QuQTtLzJOcNs+GYQzctoXUwkKB2ujtbqRx+fmkn4jJ+lm+jovNjGFGKjFex+pG3uAJStmuidh6fpvx5fKUiyBHyLse2R3BjYi6XnGimUie/W5qF6E5Nq+b6CVuku8nsLU74yCcijLGoRON6mEkCvK6h0B/Xb1Crzt/1kRUUGll4eA4f0eZ9VF5Q++6StgBDo7x09H7IbLPYwAgL5RE7lMOTA== Received: from DM6NAM10FT067.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e86::49) by DM6NAM10HT146.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e86::399) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Mon, 10 Aug 2020 13:27:56 +0000 Received: from BYAPR05MB6535.namprd05.prod.outlook.com (2a01:111:e400:7e86::47) by DM6NAM10FT067.mail.protection.outlook.com (2a01:111:e400:7e86::252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16 via Frontend Transport; Mon, 10 Aug 2020 13:27:56 +0000 Received: from BYAPR05MB6535.namprd05.prod.outlook.com ([fe80::fc6c:38b0:fa18:f355]) by BYAPR05MB6535.namprd05.prod.outlook.com ([fe80::fc6c:38b0:fa18:f355%7]) with mapi id 15.20.3283.014; Mon, 10 Aug 2020 13:27:56 +0000 To: Derick Rethans , PHP Developers Mailing List Thread-Topic: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change Thread-Index: AQHWbvIBydbCX+rhJUWK/r8c7hnlt6kxViJi Date: Mon, 10 Aug 2020 13:27:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:10FAAE5655024194307869F707C14EA59C64D721DF6F1880DF019581F8006CE0;UpperCasedChecksum:F01B669A74FAAE307DDB3332C6DB0ADBDBE1615CD0C657241BD743314CCE73B9;SizeAsReceived:6925;Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [j5+25FsoBXqOY1P9jR1LCMvMHguuuC2a] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 48b912e9-9796-4433-12cf-08d83d313180 x-ms-traffictypediagnostic: DM6NAM10HT146: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lpEwaBuwY+G3RinZYg2Qo+d+9jSBNnO5BHVunP3e2mH0/kciisotKQbF7leXVKtP1XWV75nzCLDgcAmbgNE1d8Mmt9aYP/xPl9lbhbMNC3frUJZcSHQQ6ggA/j4RipjVrdQFzcCWnhTJLBhaWifyK8fEoGGJ3ehEhZ7Ite2bYBTRPOaS8oacvFqljHgcjQrfW8+ehsTxvl5AGh7cyPZVB2qpM30mAYKFxbfr5BMsYn7wLUFqMvcr7Ts/YQpiFZMN 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: zbXdbGejhQ2OqW6V+G8VEySxH7ctsiMl4a7OpGRzfu12OnQowE8p55J+XmrCyqcvn9QrK3dryc69gBRSEzwiLtq235WVQT2SbfgTLIaDlHSFkqBRhaF+O9W+HwewhMpKuJJT2hvD3ki3p+dOB2Kr8g== 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-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: DM6NAM10FT067.eop-nam10.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 48b912e9-9796-4433-12cf-08d83d313180 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2020 13:27:56.5694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM10HT146 Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change From: theodorejb@outlook.com (Theodore Brown) On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote:=0A= =0A= > I've just opened the vote to make sure we don't make a terrible mistake= =0A= > with using the @@ syntax for attributes:=0A= > =0A= > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting=0A= > =0A= > The first vote is a vote to say that you have an opinion about attribute= =0A= > syntax. Make sure to read up on the discussion on the mailinglist if you= =0A= > haven't done so yet.=0A= =0A= I voted "No", as the primary premise for this RFC is fundamentally flawed:= =0A= =0A= > The main concern is that @@ has no ending symbol and it's inconsistent=0A= > with the language that it would be the only declaration or statement=0A= > in the whole language that has no ending termination symbol.=0A= =0A= As I pointed out in the discussion thread, this simply is not the case.=0A= Attributes are not standalone declarations or statements, but modifiers=0A= that always come before a declaration and add metadata to it. This=0A= is consistent with visibility modifiers and type declarations (which=0A= are not necessarily a single word):=0A= =0A= # declaration modifiers do not have end/grouping symbols like this=0A= @[MyAttr([1, 2])]=0A= [public] function foo(@[Deprecated] [int|float] $bar) {}=0A= =0A= # this is more consistent:=0A= =0A= @@MyAttr([1, 2])=0A= public function foo(@@Deprecated int|float $bar) {}=0A= =0A= > The second vote is an STV vote.=0A= > =0A= > In STV you SHOULD rank *all* choices, but don't pick the same one more=0A= > than once, as that will invalidate your vote.=0A= > =0A= > Please have a objective look at the table=0A= > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and= =0A= > don't just go by asthetics.=0A= =0A= I find this table to be unfortunately incomplete. E.g. why doesn't it=0A= bold the number of required characters for @@, since this is one of=0A= its advantages? And why is "Allows Grouping" marked as an advantage=0A= for the other three syntaxes? Grouping adds implementation complexity,=0A= leads to unnecessary diff noise, and is rarely more concise than @@ in=0A= real-world use cases.=0A= =0A= I also find it concerning that the RFC doesn't have an example for each=0A= consideration showing how one syntax addresses it better than another.=0A= For example, the Shorter Attribute Syntax RFC showed potential nested=0A= attributes and how @@ would support them more cleanly, but this RFC=0A= fails to mention them anywhere.=0A= =0A= Finally, while the table mentions that each syntax other than <<>> has=0A= a BC break, I think it's just as important to consider the *size* of=0A= the breaking change. #[] and @[] are larger BC breaks than @@ since=0A= they break useful syntax:=0A= =0A= // with #[]=0A= #[x] code like this would break=0A= $val =3D ['new value']; #['old value'];=0A= =0A= // with @[]=0A= $x =3D @[foo(), bar()]; // this code would break=0A= =0A= Both of these are useful patterns, and I'm not convinced that breaking=0A= them is justified. Shouldn't there be a Backward Incompatible Changes=0A= section in the RFC with these examples?=0A= =0A= Best regards, =0A= Theodore=