Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110892
MIME-Version: 1.0
References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
 <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com> <CA+kxMuS4TwAz9gaZ0GRwsb1yw5=Y+GcarPqxJsb0QC7JY9CFkw@mail.gmail.com>
In-Reply-To: <CA+kxMuS4TwAz9gaZ0GRwsb1yw5=Y+GcarPqxJsb0QC7JY9CFkw@mail.gmail.com>
Date: Thu, 9 Jul 2020 12:55:56 +0100
Message-ID: <CALKiJKo1JWTOk7qpWMt2tpeziqft7_2hXfSAStNRRoSavsrs=g@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eb2c2d05aa00e8a9"
Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000eb2c2d05aa00e8a9
Content-Type: text/plain; charset="UTF-8"

On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd <Danack@basereality.com> wrote:

> On Tue, 7 Jul 2020 at 15:47, Larry Garfield <larry@garfieldtech.com>
> wrote:
> >
> > This has reached the 2 week mark, but there's not been much discussion.
>
> Unless I'm having a massive reading failure, this RFC has been
> announced twice. And feedback was provided before:
>
> https://externals.io/message/109646#109647
> https://externals.io/message/109646#109648




It seems that, although still labelled version 1, the RFC has been
substantially rewritten since that discussion.




> From the RFC:
> > Every new global class, however, creates a potential namespace collision
> > with existing user-space code and thus a potential for backward
> > compatibility breaks.
>
> This doesn't appear to be an actual problem for the PHP ecosystem.
>
> The vast majority of code in libraries is in namespaces, which avoids
> there being a problem that needs addressing.
>



And yet we have repeatedly had discussions about whether this or that
feature should or shouldn't be prefixed with a namespace. If you think the
correct answer to "when should we use the PHP\ prefix?" is "never", I urge
you to put forward an RFC making that the policy.




> Rather than having more rules (quite a few of which I don't agree
> with), time and effort would be better spent on reviewing code and
> using features before releases e.g. to avoid situations like the FFI
> api being difficult to use.
>


This is pure whataboutery; the idea that reading a few naming conventions
will be such a burden that somebody would have no time to review a feature
is frankly ridiculous. Nor will the lack of a naming convention mean that
no time needs to be spent naming things - quite the contrary, it will mean
more time is wasted debating every case.

It's worth stressing that naming conventions are not new - we've had them
for global functions for many many years. We may talk about "putting things
into namespaces", but PHP's namespaces really are just names, so this RFC
could easily be called "update naming conventions for classes".

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000eb2c2d05aa00e8a9--