Everything

php

Home » Project » Newsgroups » php.internals » [RFC] \PHP namespace usage heuristics »

[RFC] \PHP namespace usage heuristics

php.internals

Larry Garfield

6 years ago

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

Rowan Collins

6 years ago

On 24/06/2020 01:30, Larry Garfield wrote:

> * 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

Hi Larry,

Thanks for moving forwards with this. To stretch an analogy, I think
we're better off picking out the colour scheme for this bikeshed in
advance, rather than just resolving to buy some paint when we need it. :)


One section that gave me pause reading the RFC was this:

> A component namespace is “claimed” by the RFC that first uses it.

Once claimed, that component namespace may only be used only by that RFC
or future RFCs that extend that one in a natural way.

PHP RFCs tend to describe a change rather than a full feature, and once
accepted are more a historical record of the change than a living
reference. Perhaps it would make sense to create an IANA-style
"registry" of reserved "component namespaces", so that RFCs could add,
and more rarely amend, entries in a central location.

This doesn't need to be elaborate - just a table on a wiki page
somewhere, with columns such as name, usage definition, status (e.g.
unused but reserved for forward/backwards compatibility), and maybe
notes on naming conventions within the component (use of sub-namespaces,
suffixes, etc).


One thing the RFC doesn't tackle in detail is what we might call The
PECL Question: what are the processes when an extension moves from PECL
to php-src (like ext/sodium) or from php-src to PECL (like ext/mysql)?

For moves into PECL, the RFC says that the component namespace "remains
reserved". If we were maintaining a registry, this could include links
to PECL with appropriate status notes.

For moves out of PECL, it's trickier. If we have PECL extensions listed
on the registry, we could have some way to register them *before* the
extension is added to core; but I'm not quite sure what that process
would look like, and what kind of endorsement it would imply of the
extension.

If we don't do that, what would happen when an extension becomes part of
core and needs to rename functionality from "Foo\Something" or
"SomeCorp\Foo\Something" to "PHP\Foo\Something"?

One answer would be to follow the same process as renaming functionality
already in core - i.e. include the old names as aliases, subject to
deprecation over a major version cycle. This would help users migrating
from the PECL extension, but users of "vanilla" php-src might be
confused why there are two names. Worse, it would defeat part of the
point of the PHP\* namespace, since php-src would be claiming names
outside it which could conflict with other projects.

Perhaps a cleaner approach would be to add the extension with only the
new PHP\*  names, and provide a userland polyfill for users upgrading
from the PECL extension?


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Larry Garfield

6 years ago

On Wed, Jun 24, 2020, at 2:32 PM, Rowan Tommins wrote:

> On 24/06/2020 01:30, Larry Garfield wrote:
> > * 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
>
>
> Hi Larry,
>
> Thanks for moving forwards with this. To stretch an analogy, I think
> we're better off picking out the colour scheme for this bikeshed in
> advance, rather than just resolving to buy some paint when we need it. :)

Ha!  An apt analogy, yes.

> One section that gave me pause reading the RFC was this:
>
>  > A component namespace is “claimed” by the RFC that first uses it.
> Once claimed, that component namespace may only be used only by that RFC
> or future RFCs that extend that one in a natural way.
>
> PHP RFCs tend to describe a change rather than a full feature, and once
> accepted are more a historical record of the change than a living
> reference. Perhaps it would make sense to create an IANA-style
> "registry" of reserved "component namespaces", so that RFCs could add,
> and more rarely amend, entries in a central location.
>
> This doesn't need to be elaborate - just a table on a wiki page
> somewhere, with columns such as name, usage definition, status (e.g.
> unused but reserved for forward/backwards compatibility), and maybe
> notes on naming conventions within the component (use of sub-namespaces,
> suffixes, etc).

I didn't want to over-reach, as I am not familiar enough with other Wiki processes etc. to know what the rules would be for establishing such a registry.  I agree it's a good idea, though, if someone can suggest workable logistics.  A wiki page or a page in docs would both make sense to me.

> One thing the RFC doesn't tackle in detail is what we might call The
> PECL Question: what are the processes when an extension moves from PECL
> to php-src (like ext/sodium) or from php-src to PECL (like ext/mysql)?
>
> For moves into PECL, the RFC says that the component namespace "remains
> reserved". If we were maintaining a registry, this could include links
> to PECL with appropriate status notes.
>
> For moves out of PECL, it's trickier. If we have PECL extensions listed
> on the registry, we could have some way to register them *before* the
> extension is added to core; but I'm not quite sure what that process
> would look like, and what kind of endorsement it would imply of the
> extension.
>
> If we don't do that, what would happen when an extension becomes part of
> core and needs to rename functionality from "Foo\Something" or
> "SomeCorp\Foo\Something" to "PHP\Foo\Something"?
>
> One answer would be to follow the same process as renaming functionality
> already in core - i.e. include the old names as aliases, subject to
> deprecation over a major version cycle. This would help users migrating
> from the PECL extension, but users of "vanilla" php-src might be
> confused why there are two names. Worse, it would defeat part of the
> point of the PHP\* namespace, since php-src would be claiming names
> outside it which could conflict with other projects.
>
> Perhaps a cleaner approach would be to add the extension with only the
> new PHP\*  names, and provide a userland polyfill for users upgrading
> from the PECL extension?

Mark had discussed having a \PHP\Ext\ namespace for extensions.  I deal with extensions rarely enough that I don't have a strong opinion on the matter.  I'm fine with no Ext segment, but if others feel strongly about having it that's good too.  Whatever is agreeable works for me.  We could also pre-reserve a namespace for PECL packages in general to use if that makes sense to people.

For transitioning in/out, my feeling is:

* On the way in, it's a new feature for php-src so follows the same rules as any other new php-src code.
* User-space polyfills should be a reasonable and straightforward thing to do *most* of the time, so that's fine.
* On the way out, the namespace remains reserved for a while so a user-space polyfill is just as viable.
* These are heuristics, not absolute rules, so if a particular extension really really has need to be different that's OK, and we explicitly give ourselves wiggle room should that be needed.  The goal here is to make it clear what the default policy is and where the burden of proof is to demonstrate a need to be non-default.

--Larry Garfield

Mike Schinkel

6 years ago

> On Jun 23, 2020, at 8:30 PM, Larry Garfield <larry@garfieldtech.com> 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*
>

This looks really good Larry. Very well thought-out.

If I could vote it would be a definitive "Yes."

-Mike

Larry Garfield

6 years ago

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.

Mark Randall

6 years ago

On 07/07/2020 15:46, Larry Garfield wrote:

> This has reached the 2 week mark, but there's not been much discussion.  Anyone else want to weigh in?

We wanted to add that, general sentiment seems to be moving towards
using Exceptions for communicating errors, potentially including a large
effort towards it for 8.1.

This would mean that each extension would likely need to add many of its
own exception classes to build up a full hierarchy, all of which, in the
current setup, would go into root.

With this RFC passed we could realistically expect them to be placed
into their respective namespaces keeping the whole thing much more self
contained and tidy.

Mark Randall

Peter Bowyer

6 years ago

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.
> Anyone else want to weigh in?
>

Looks good; nothing more to say. 👍

Peter

Dan Ackroyd

6 years ago

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

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.

> Anyone else want to weigh in?

I still don't think this RFC is a good way to improve the general
situation of PHP.

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.

cheers
Dan
Ack

Rowan Collins

6 years ago

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]

Larry Garfield

6 years ago

On Thu, Jul 9, 2020, at 6:55 AM, Rowan Tommins wrote:

> 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.

Yes, based on the discussion in chat that resulted in actual guidelines, we mostly rewrote the whole document.  I've no idea what the rules are around new version numbers of RFCs that haven't been up for a vote yet.

> > 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.

Which guidelines in particular bug you, and why?

>
> 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".

I fully agree that this is a why-not-both-girl.gif situation.  If anything, reducing the time that gets spent asking "*now* can we start using a namespace?" will open up more time for people to actually review APIs.  Although since those are two very different mindsets I doubt that there will be any impact on available-API-review time either way.  (That said, more time and attention paid to developing clean, usable APIs can only benefit PHP.)

--Larry Garfield

Dan Ackroyd

6 years ago

On Thu, 9 Jul 2020 at 18:04, Larry Garfield <larry@garfieldtech.com> wrote:

>
> I've no idea what the rules are around new version numbers
> of RFCs that haven't been up for a vote yet.

I pretty strongly recommend people against re-using documents. If it's
going to change significantly, using a new doc makes it easier to see
it's a different idea.

Alternatively summarising the changes might be more appropriate for
smaller changes.

Larry wrote:

> Which guidelines in particular bug you, and why?

Just to note, my problem isn't just with the details, but to pick out a few.

RFC text:

> Any namespaced code provided by PHP-SRC will use a sub-namespace of \PHP.
> That is, no PHP\Foo class may be defined,

That seems like something that will have reasonable exceptions to.

RFC text:

> Classes that are part of a disable-able extension
> Eg, \PHP\Sodium.

I don't believe extensions should necessarily be under a PHP
namespace. Instead that should be thought about case-by-case. Also,
extensions can move from being one that can be disabled to not being
disable-able.

RFC text:

> Upgrade path for existing classes
> That is, a rename introduced in PHP 8.2 is not eligible to have its
> old name removed until at least 10.0.

The reason for having aliases is mostly to allow easier upgrading. i.e.

i) User code runs on version x.y of PHP.
ii) User code runs on version x.(y+1) of PHP.
iii) The user changes any use of old names on x.(y+1).
iv) Old names can be remove in version x.(y+2)

Keeping aliases of old names around for longer than that isn't that
useful. But again, this should be thought about case-by-case.

Rowan Tommins wrote:

> 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.

That's getting pretty close to just name-calling.

It's fine to think that there is a problem here, and that adopting
this RFC is an appropriate solution to that problem.

But I think that there isn't really a problem to solve here, and that
even if there is, solving it through an RFC is worse than just
ignoring the problem.

This difference in approach possibly comes from a difference in
philosophy. aka I think we're both making sensible arguments, but
based on different values of what is important, and so coming to
different conclusions.

I've recommended the book Systemantics before:
https://en.wikipedia.org/wiki/Systemantics It has lots of very useful
advice about the counter-intuitive results that emerge from decisions.
And it's from that approach to systems design that I'm basing my
thinking. One of the most simplest pieces of advice it gives is:
"First rule of systems design: do without out one if possible"

And one of the few pieces of advice that I give to people, that I'm
pretty sure is right is: "Accept you're going to be wrong - Make it
easier to correct mistakes." which was part of a whole talk I gave at
DPC*

I don't think this RFC provides much benefit now, and I don't think it
makes it easier to name things in the future. In fact it makes things
more difficult as any exceptions to the rules laid down in this RFC
now become "DEVIATIONS FROM OUR ALREADY DECIDED RULES!!1!" rather than
things that can be thought about as code, coding standards, and
people's personal preferences all evolve.

cheers
Dan
Ack

* Video: https://www.youtube.com/watch?v=TS9BNa1MDW0
Slides: http://docs.basereality.com/GoodOrBad_DPC/

Apologies for the quality of my voice which made the presentation
quality not as high as I had hoped. But it does lead to the 2nd piece
of advice I'm pretty sure is correct, which is "wear a seatbelt so you
don't damage your spine in a car crash" which might seem kind of
obvious advice in retrospect.

Derick Rethans

6 years ago

On Thu, 9 Jul 2020, Rowan Tommins wrote:

> 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.

That is already the policy:
https://www.php.net/manual/en/userlandnaming.rules.php

Specifically "PHP owns the top-level namespace but tries to find decent
descriptive names and avoid any obvious clashes"

cheers,
Derick

Rowan Collins

6 years ago

On Thu, 9 Jul 2020 at 18:14, Derick Rethans <derick@php.net> wrote:

> On Thu, 9 Jul 2020, Rowan Tommins wrote:
>
> > 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.
>
> That is already the policy:
> https://www.php.net/manual/en/userlandnaming.rules.php
>
> Specifically "PHP owns the top-level namespace but tries to find decent
> descriptive names and avoid any obvious clashes"
>

That is not the same thing at all. That states that PHP may use the global
namespace; it doesn't say it will never use any other namespace.

And https://www.php.net/manual/en/language.namespaces.rationale.php says
essentially the same thing about the PHP\* namespace:

> The Namespace name *PHP*, and compound names starting with this name

(like *PHP\Classes*) are reserved for internal language use and should not
be used in the userspace code.


At the very least, it is not universally accepted that the policy is never
to use the PHP namespace, or we wouldn't keep having this conversation.

So, again, if anyone thinks that the policy should be to never use the PHP\
namespace prefix, please put it to a vote. (I'm quite tempted to do it
myself from a position of Devil's Advocate.)


Regards,

--
Rowan Tommins
[IMSoP]

Nikita Popov

6 years ago

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

Larry Garfield

6 years ago

On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote:

> 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

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

Mark Randall

6 years ago

On 10/07/2020 09:54, Nikita Popov wrote:

> 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.)

There is another option that we reserve \Ext as well (not \PHP\Ext)

\PHP stays for engine level classes (core, collections etc)

\PHP\Annotations\JIT
\PHP\Tokenizer\Token
...

\Ext gets used for extensions, including bundled extensions. Anyone with
good standing can request an \Ext (or could use one without requesting
it, but it wouldn't be a BC break if an officially approved extension
took its name).

\Ext\Mysqli\Connection
\Ext\Mysqli\Result
\Ext\Gd\Image
\Ext\Curl\Handle
...

This would also solve the long-problem of an ever-increasing number of
classes and symbols placed into the root namespace.

Michael Wallner

6 years ago

Hi Larry!

Larry Garfield <larry@garfieldtech.com> schrieb am Mi., 24. Juni 2020,
02:30:

> Greetings, Internalians.
>
> *dons flame retardant suit*

Thank your for your efforts, but I'm about to cast a negative vote on this
policy.

Distilled down, I just cannot see any huge benefit out of a (or two) root
namespace(s). As a project we rightfully own the root namespace, and
putting everything beneath PHP just doesn't make any sense to me.

Also, most code more than a handful of files is already vendored, and if
not a common idiom I see often used, is a simple 'app' or '<appname>'
namespace.

Closing, just let me ensure that it is not because one of my extensions
accidentally provides a class beneath a 'php' namespace.

Regards,
Mike

Rowan Collins

6 years ago

On Mon, 20 Jul 2020 at 16:58, Michael Wallner <mike@php.net> wrote:

> Distilled down, I just cannot see any huge benefit out of a (or two) root
> namespace(s). As a project we rightfully own the root namespace, and
> putting everything beneath PHP just doesn't make any sense to me.
>

I will ask you the same question I have asked others, but without much
response: would you vote Yes to an alternative proposal to officially adopt
a policy of _never_ using the PHP\* namespace, to eliminate future debates
about when to use it?

Regards,

--
Rowan Tommins
[IMSoP]

Mark Randall

6 years ago

On 20/07/2020 16:58, Michael Wallner wrote:

> Distilled down, I just cannot see any huge benefit out of a (or two) root
> namespace(s). As a project we rightfully own the root namespace, and
> putting everything beneath PHP just doesn't make any sense to me.

You cannot just "own" the root namespace if you want to use namespaces
yourself, which we will, it's inevitable, the number of classes and
interfaces increases more and more each release.

So either you fake namespaces e.g. PhpToken or you trample on userland
\Tokenizer.

There is one solution to this, and that is to have a vendor namespace
for the PHP project itself, naturally the one that is reserved, \PHP.

There's a very good reason modern language frameworks claim a couple of
root level namespaces, e.g. .NET it's System.* and Microsoft.*, for Java
it's java.*