Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111033
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: [RFC] Treat namespaced names as single token,
 relax reserved keyword restrictions
Thread-Index: AQHWVf4EgDi8slE9I02lWaW55PpJk6kG0QMAgAKcUPQ=
Date: Thu, 16 Jul 2020 01:40:16 +0000
Message-ID:
 <DM6PR07MB66182B39AC3575CD7F5B8326F97F0@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <CAF+90c9ow-_=DSZ9LFhKzA1ZgHcf0LPt-p7tnhKRcgVUBnLfZw@mail.gmail.com>
 <CAF+90c8m_4v_fdJfFMH+mHRf7qxps1zzrmCbVsAfQOjBmOhqFw@mail.gmail.com>,<CAF+90c_hjNrsOfesH=y4_cUPj5J2KsWH0e83xnrXsaV0eX_HLw@mail.gmail.com>
In-Reply-To:
 <CAF+90c_hjNrsOfesH=y4_cUPj5J2KsWH0e83xnrXsaV0eX_HLw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [ZdS03qeU2i3DP3TOzdaw1W+RoZBJz4gj6BpSI0e7s8EnmsklitSRuyGUTVOUekX2]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 2dbf8676-c1ca-4085-5bc9-08d8292930c3
x-ms-traffictypediagnostic: BN8NAM11HT209:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 /zEP1PvQWSah3q4yzOJtyVEuK4OsD2gTHo+BTEByeJ0cQRHR08qrLpNb8d0rBVXCG/vmstHas4A35gnGRHN82MvVBMVVRIAHWgC6gjgc9njm2pouYf2yoxWBC+TYvF96vxe7UROwcls1raWe7oigj0UYeYnKhORs9+KXnYldeigAtTvTHgEgniT8PfuYw/Jy7y7bJaPyYx1s3uTdlbJrZf+n0VfDutTAmGDKDaxpI5+FI5L+ECr43+SVMc7l22s3
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR07MB6618.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 4WzPyyTM4jVTwHNo5lZAEgMlNo/pASmn/vhGASmBS10mEkx1NIgCJe0S2VfFNx1IdANupapgZIwT+P7aSddnqGUstZj2n9GZap2B/ZI5ZS6lTm/lVrvybjpqFHXCtHxJ9hGfzAPmFSttcOzHV67d8DR6d8wbIiNIa9UQrRIcmoIIAD2nZDJ6g8mrSlfbrgiyLiCyt7FeYIua3ryhYfOJkg==
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: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT049.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2dbf8676-c1ca-4085-5bc9-08d8292930c3
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2020 01:40:16.0723
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM11HT209
Subject: Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax
 reserved keyword restrictions
From: tysonandre775@hotmail.com (tyson andre)

> > I have reduced the scope of this RFC to handle just the issue of=0A=
> > namespaced names, without touching any other reserved keyword restricti=
ons.=0A=
> > As the discussion shows, those are trickier, with more cases of perceiv=
ed=0A=
> > ambiguity that may need to be mitigated.=0A=
> >=0A=
> > As this proposal is now a prerequisite for=0A=
> > https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a=
=0A=
> > disturbing number of people that they might vote against this proposal,=
 not=0A=
> > because they disagree with it, but because that would prevent the adopt=
ion=0A=
> > of the @@ attribute syntax. I'm not sure what to do about that...=0A=
> >=0A=
> =0A=
> Heads up: I plan to open voting on this proposal tomorrow, unless there i=
s=0A=
> further feedback.=0A=
=0A=
One possibility would be to split it up into two separate RFCs:=0A=
(This would probably be too short notice, and this isn't similar to any pro=
posal in the past)=0A=
=0A=
1. An Yes/No RFC requiring a 2/3 majority for accepting the amended `@@` at=
tribute syntax with the restriction the original RFC proposed (no whitespac=
e&reserved words.=0A=
=0A=
   I'd think that very few proponents of `@@` had plans to mix whitespace w=
ith backslashes in attributes when reading that RFC, and it's extremely sim=
ilar to the original attribute syntax change RFC.=0A=
=0A=
2. A yes/no RFC for this RFC to affect everything except the choice of attr=
ibute syntax.=0A=
   (i.e. if 2 passes but not 1, we'd end up using `<<Attribute\Name>>` in 8=
.0 and forbidding `<<Attribute \ Name>>`)=0A=
=0A=
Still, my proposal seems like a dissatisfying one.=0A=
=0A=
Allowing future 3+-way votes to be re-voted once due to unexpected implemen=
tation concerns=0A=
(when the original authors are among the authors of the amendment)=0A=
with a 50% majority requirement (instead of 2/3) might help in the future,=
=0A=
but would probably entail its own process vote for an extremely rare/narrow=
 RFC situation.=0A=
That wouldn't help with this RFC due to the feature freeze,=0A=
and I think that situation's too rare to actually work out details and actu=
ally propose that amendment.=0A=
=0A=
P.S. I'm in favor of removing whitespace between tokens of names.=0A=
=0A=
- Tyson=