Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111254
To: Mark Randall <marandall@php.net>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Thread-Index: AQHWZO4EZIMJMorBK0qxy5SLq6JXCakdN4bOgAAr8wCAACScWoAAFkOAgAFOusY=
Date: Wed, 29 Jul 2020 19:08:25 +0000
Message-ID:
 <BYAPR05MB6535380F0E90AC5D745F18D2DE700@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
 <BYAPR05MB6535E638D874FB9D6653411CDE730@BYAPR05MB6535.namprd05.prod.outlook.com>
 <b388d02a-9baa-481e-bf49-3aad1c467880@DB3EUR04FT028.eop-eur04.prod.protection.outlook.com>
 <BYAPR05MB65352C42F9A050AAE405D866DE730@BYAPR05MB6535.namprd05.prod.outlook.com>,<a49e2f4d-d366-432d-b405-f5adaffc66d6@VE1EUR01FT022.eop-EUR01.prod.protection.outlook.com>
In-Reply-To:
 <a49e2f4d-d366-432d-b405-f5adaffc66d6@VE1EUR01FT022.eop-EUR01.prod.protection.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [G3yD2VDFm01XQfC4fe6/qELBp2w33BvW]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: ab87df30-d5b8-4118-432f-08d833f2c54b
x-ms-traffictypediagnostic: MW2NAM10HT034:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 ZXLmcCPqx6WLhfacjHdkR42CKjBBvlSdeWm19X24PVFa2zXy/b4rExPpoSdNcLJxlMPQqqmrYDAoXEY7Y7/dDQO+3+jOdcMpGFv8Fm2QFvushuM+IyFKDPziEX/xtOnehaTCvm+cN+4NJO+u5RtTHJw0VxgdFDN2/WDDuaEPNsgQ6i8QSuXfc9dbysAs/a4ZzTYMiDWW0VDwiEBiaJlRWK9d1DeB1gXdH7WXcPc9MQIIotSthUVbmFncaYm6Z9WC
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:
 n6y2oVST3FPqWoatUZVVW5tAQQ5GCMjSGevPcHYaB/OmV3+GRnG5u9d9mYNctsS2QVnbaoicHk8twbxYrWEM+9vVqxgncUBF+fwM2n4Mk1WzIEpfZT4ZJSiNtdSen2Y0Jfgp8yEkb/xDMF6r3+gRWg==
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: MW2NAM10FT015.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: ab87df30-d5b8-4118-432f-08d833f2c54b
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 19:08:25.7651
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM10HT034
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: theodorejb@outlook.com (Theodore Brown)

On Tue, July 28, 2020 at 6:09 PM Mark Randall <marandall@php.net> wrote:=0A=
=0A=
> On 28/07/2020 22:55, Theodore Brown wrote:=0A=
> > I appreciate the examples. I think there are good reasons not to=0A=
> > implement these kind of extensions, at least in this form. I'll reply=
=0A=
> > to each example below.=0A=
> =0A=
> =0A=
> The problem is your argument comes from a position of... because you=0A=
> don't like those examples, we shouldn't make accomodation for them or=0A=
> anything like them in future.=0A=
> =0A=
> Adopting such extensions is a matter for a future RFC, and not for=0A=
> preemptively throwing a spanner in the works.=0A=
=0A=
Hi Mark,=0A=
=0A=
Future RFCs are as free as they've always been to propose new=0A=
additions and extensions. Do you think we need to choose a more=0A=
verbose syntax for every new feature in PHP just to make sure it=0A=
accommodates keyword flags on the off-chance we may want to add them=0A=
later?=0A=
=0A=
E.g. should we re-vote on the named arguments RFC now and replace the=0A=
syntax with something designed around adding flags to each argument=0A=
(e.g. so that function calls could support both an old and new=0A=
parameter names and be compatible with multiple library versions)?=0A=
=0A=
There's good reason to believe that such added complexity is not=0A=
the best approach, and is very unlikely to be accepted. Preemptively=0A=
implementing a more verbose syntax with a larger BC break, on the=0A=
basis of hypothetical extensions which haven't been needed in any=0A=
other language isn't a good approach to language design, in my view.=0A=
=0A=
Anyway, apart from the fact that feature freeze is less than a week=0A=
away, it seems like voting again to use #[] instead of @@ would=0A=
violate the voting rules. [1] It hasn't been six months since the=0A=
last vote, and this proposal is identical to the one declined in the=0A=
previous RFC.=0A=
=0A=
Best regards,  =0A=
Theodore=0A=
=0A=
[1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals=