On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote:
> On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield <la...@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
> > > la...@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
Hi Nikita.
I'm open to ways of handling that. As written right now, yes, a hypothetical
\PHP\Foo extension getting moved to PECL should get renamed to \MyCorp\Foo (or
whatever). However, it should be reasonably straightforward in most cases to
include a user-space shim that does:
namespace \PHP\Fop {
class Service extends \MyCorp\Foo\Service {}
}
(Or similar.)
And the same for an extension moving into core.
I don't really see any alternative that doesn't either:
1) Essentially boil down to that.
2) Allow arbitrary extensions to share a namespace with core code.
Eg, one could say that core-packaged extensions and PECL both use \Ext, and
\PHP is reserved for the engine proper. However, there's not a great deal in
the engine proper, and stuff still sometimes moves from the engine to an
extension or vice versa, so it's the same problem just moved elsewhere.
I don't expect a namespace vacated by an expelled extension to ever get reused
in practice. The RFC established the mechanism by which it could be reclaimed,
which I think is important for completeness, but in practice I highly doubt it
ever would be without an extremely strong case being made.
As I said, I'm open to other ideas for how to handle that move, but I don't
really see any ideal ones.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
