Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110911
MIME-Version: 1.0
References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com> <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com>
In-Reply-To: <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com>
Date: Fri, 10 Jul 2020 10:54:21 +0200
Message-ID: <CAF+90c-rkgOdJMo=NFi1PKAKg+r56R26EmMDotZKQf19+z2Htw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009d0cae05aa127d38"
Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000009d0cae05aa127d38
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > Greetings, Internalians.
> >
> > There has been much talk of the \PHP namespace of late, including one
> > unsuccessful RFC.  In the discussion, the pushback broke down into two
> > main camps:
> >
> > * We should never namespace anything ever.
> > * We can namespace things but we need something more concrete than
> > "RFCs can namespace things if they feel like it."
> >
> > I can't do much about the former, but the latter is a solvable problem.
> >  To that end, Mark Randall and I have put together a new RFC on the
> > topic, based on a fruitful discussion in Room 11 a few weeks ago to
> > brainstorm what actual guidelines should be for what goes where.
> >
> > https://wiki.php.net/rfc/php_namespace_policy
> >
> > This proposal provides guidance to short circuit future subjective
> > bikeshedding, while still leaving some wiggle room for case-by-case
> > evaluation as needed.  That makes it different from prior attempts that
> > did not provide clear guidance for future RFC authors.
> >
> > The specific guidelines offered may or may not appeal to you; those are
> > open to discussion (within reason; we don't want to end up back in "do
> > whatever" land as we know that won't help), but the more important
> > point is that clear guidelines are provided.
> >
> > Also of note, although it uses existing code to demonstrate where
> > classes *would* go under this plan it does not immediately move
> > anything.  Those are left for future RFCs that would have to stand or
> > fall on their own merit.  It also provides for a very long grace period
> > for any such transitions to minimize disruption.
> >
> > The intent is to bring this proposal to a vote in time for 8.0's freeze
> > one way or another, even though it's unlikely to have any impact on 8.0
> > itself.  It's still a convenient deadline.
> >
> > *dons flame retardant suit*
> >
> > --
> >   Larry Garfield
> >   larry@garfieldtech.com
>
> This has reached the 2 week mark, but there's not been much discussion.
> Anyone else want to weigh in?
>
> I want to give it a few more days and possibly revise it to include a Wiki
> page as suggested, but probably will bring it to a vote within the next
> week or so.
>

Hey Larry,

As far as I can see, this RFC still doesn't address a primary concern from
previous discussions: Extensions may get moved between PHP and PECL. The
only discussion of this issue seems to be this bullet point:

> If a feature is removed from PHP-SRC (either to PECL or dropped entirely)
its previously claimed component namespace remains reserved. It MAY be
released by a subsequent RFC, following the standard RFC procedure, at
least one minor version after the feature is removed. That delay is to
minimize backward compatibility impact and allow userland code to migrate
if appropriate.

To reiterate what the problem is: If the "PHP" namespace is only used by
extensions bundled with php-src, then any time we import an extension from
PECL, that means all the symbols in that extension must get renamed. This
is disruptive to any existing users of the extension, who now have to deal
with different symbol names depending on which PHP version they use.

Similarly, when extensions get unbundled and moved to PECL, my current
reading of your RFC is that the extension would initially retain the PHP\
namespace prefix, even though it is no longer vendored by PHP, but the
extension namespace may get reused at a later point in time (which seems
counter-productive to the goal of avoiding naming collisions).

For me, dealing with PHP <-> PECL moves is an important part of adopting
namespaces in php-src, and I don't think the current proposal addresses
this issue sufficiently. (One way to address it would be to drop the PHP\
prefix, and use unvendored namespace names for php-src.)

Regards,
Nikita

--0000000000009d0cae05aa127d38--