Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110297
MIME-Version: 1.0
References: <CABdc3Wrzo9s+x6i85ZWWK3UYc0LJBh+UEcZhZ07eX-iVpmt9vQ@mail.gmail.com>
 <C13EECB0-F4F4-4BB0-B90C-9CBDE9E57D94@benramsey.com>
In-Reply-To: <C13EECB0-F4F4-4BB0-B90C-9CBDE9E57D94@benramsey.com>
Date: Fri, 29 May 2020 11:23:12 +0100
Message-ID: <CALKiJKrAoYNXUSJ2dtg-jRq6KPbSUDs0DQX4kU6eN3LQ1kANBA@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cb383f05a6c6d5f7"
Subject: Re: [PHP-DEV] [RFC][VOTE] PHP Namespace in core
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000cb383f05a6c6d5f7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 28 May 2020 at 19:53, Ben Ramsey <ben@benramsey.com> wrote:

>
> In light of recent discussions on attribute naming schemes, I=E2=80=99m
> concerned that future RFC discussions will be riddled with noisy
> back-and-forth messages concerning what and how to name things. I=E2=80=
=99m 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=E2=80=99s be=
tter 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,
--=20
Rowan Tommins
[IMSoP]

--000000000000cb383f05a6c6d5f7--