On Thu, 28 May 2020 at 19:53, Ben Ramsey wrote:
>
> In light of recent discussions on attribute naming schemes, I’m
> concerned that future RFC discussions will be riddled with noisy
> back-and-forth messages concerning what and how to name things. I’m not
> passing any judgement on these types of conversations, since I agree
> that naming things is important, but I also think the use of a
> specialized namespace for core symbols is inevitable, and it’s better to
> tackle this now than later.
>
The problem with this RFC, to me, is that it doesn't actually prevent any
of those noisy back-and-forth discussions.
With this policy in place, it would still be a topic of debate on every RFC:
* Whether the functionality is "tightly coupled to the PHP engine", just as
we used to debate whether something was "a feature affecting the language
itself" and therefore require a higher voting threshold
* If the answer is "no", should a new feature go into the PHP\ namespace
anyway, as implied by the Future Scope section?
* Should the class be _directly_ in PHP\ or some new or existing
"project"-level sub-namespace?
* Should *that* level be flat, or be organised into a further hierarchy?
* If there's a named project level, should the class name repeat that name
(PHP\Attributes\Jit vs PHP\Attributes\JitAttribute)?
...and so on. To use a hackneyed metaphor, it's a general agreement that
the bikeshed needs painting, and we'll decide the colour later.
No naming convention can perfectly cover every future situation, and
agreeing the initial text will be painful, but I think a concrete policy
with clear definitions and examples is both possible and necessary. A few
of us started brainstorming some ideas in Room 11 a few days ago; I think
it needs someone to don their flame-proof armour and edit together a first
draft so that we can discuss specifics.
Regards,
--
Rowan Tommins
[IMSoP]
