On Thu, 28 May 2020 at 19:53, Ben Ramsey <b...@benramsey.com> 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]
