Re: Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions
| From: | tyson andre | Date: | Thu, 16 Jul 2020 01:40:16 +0000 |
| Subject: | Re: Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-111033@lists.php.net to get a copy of this message | ||
> > I have reduced the scope of this RFC to handle just the issue of
> > namespaced names, without touching any other reserved keyword restrictions.
> > As the discussion shows, those are trickier, with more cases of perceived
> > ambiguity that may need to be mitigated.
> >
> > As this proposal is now a prerequisite for
> > https://wiki.php.net/rfc/shorter_attribute_syntax, I have
> > heard from a
> > disturbing number of people that they might vote against this proposal, not
> > because they disagree with it, but because that would prevent the adoption
> > of the @@ attribute syntax. I'm not sure what to do about that...
> >
>
> Heads up: I plan to open voting on this proposal tomorrow, unless there is
> further feedback.
One possibility would be to split it up into two separate RFCs:
(This would probably be too short notice, and this isn't similar to any proposal in the past)
1. An Yes/No RFC requiring a 2/3 majority for accepting the amended
@@ attribute syntax
with the restriction the original RFC proposed (no whitespace&reserved words.
I'd think that very few proponents of @@ had plans to mix whitespace with
backslashes in attributes when reading that RFC, and it's extremely similar to the original
attribute syntax change RFC.
2. A yes/no RFC for this RFC to affect everything except the choice of attribute syntax.
(i.e. if 2 passes but not 1, we'd end up using <<Attribute\Name>>
in 8..0 and forbidding <<Attribute \ Name>>)
Still, my proposal seems like a dissatisfying one.
Allowing future 3+-way votes to be re-voted once due to unexpected implementation concerns
(when the original authors are among the authors of the amendment)
with a 50% majority requirement (instead of 2/3) might help in the future,
but would probably entail its own process vote for an extremely rare/narrow RFC situation.
That wouldn't help with this RFC due to the feature freeze,
and I think that situation's too rare to actually work out details and actually propose that
amendment.
P.S. I'm in favor of removing whitespace between tokens of names.
- Tyson