# [RFC] \PHP namespace usage heuristics

- Thread: https://externals.io/message/110711
- Original archive: https://news-web.php.net/php.internals/110711
- Started by Larry Garfield on 2020-06-24T00:30:02+00:00
- Messages: 33
- RFC: PHP Namespace Policy (Declined) — https://externals.io/rfc/php_namespace_policy.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/110711.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #110711 — Larry Garfield — 2020-06-24T00:30:02+00:00

URL: https://externals.io/message/110711#110711

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

---

## #110718 — Rowan Tommins — 2020-06-24T19:32:38+00:00

URL: https://externals.io/message/110711#110718 · In reply to: #110711

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

---

## #110720 — Larry Garfield — 2020-06-24T23:11:39+00:00

URL: https://externals.io/message/110711#110720 · In reply to: #110718

> 
> > […]
> 
> 
> 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:
> 
> > […]
> 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

---

## #110746 — Mike Schinkel — 2020-06-27T16:07:40+00:00

URL: https://externals.io/message/110711#110746 · In reply to: #110711

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

---

## #110861 — Larry Garfield — 2020-07-07T14:46:35+00:00

URL: https://externals.io/message/110711#110861 · In reply to: #110711

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

---

## #110862 — Mark Randall — 2020-07-07T15:00:39+00:00

URL: https://externals.io/message/110711#110862 · In reply to: #110861

> 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

---

## #110864 — Peter Bowyer — 2020-07-07T15:12:09+00:00

URL: https://externals.io/message/110711#110864 · In reply to: #110861

> 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

---

## #110869 — Larry Garfield — 2020-07-07T22:04:21+00:00

URL: https://externals.io/message/110711#110869

> Larry Garfield wrote on 07/07/2020 16:46:
> > […]
> 
> I guess I'm missing something obvious here, but the RFC says:
> 
> > […]
> conventions.
> 
> But then in the examples you've got e.g. \PHP\DOM\ or \PHP\SPL\... isn't 
> that incorrect?
> 
> And slightly related, is there any reason to use \PHP  instead of \Php?
> 
> Sorry if this has been discussed before, I haven't seen it.
> 
> Cheers,
> Miguel

Mm, mainly because I added the CamelCase clause late and didn't think about abbreviations.  Whether it should be PHP/XML/DOM or Php/Xml/Dom has been an ongoing debate for at least since PHP 5.0.  I have no preference strong enough to die on that hill, though, so whatever voters are willing to go for I'm good with.

Anyone care enough to offer a bikeshed color?

--Larry Garfield

---

## #110870 — David Rodrigues — 2020-07-07T22:31:25+00:00

URL: https://externals.io/message/110711#110870 · In reply to: #110869

There are some problem by using double back slash for PHP namespace?

Eg. Instead of \PHP\String be just \\String.

Em ter, 7 de jul de 2020 19:04, Larry Garfield <larry@garfieldtech.com>
escreveu:

> 
> > […]
> discussion.  Anyone else want to weigh in?
> > […]
>
> Mm, mainly because I added the CamelCase clause late and didn't think
> about abbreviations.  Whether it should be PHP/XML/DOM or Php/Xml/Dom has
> been an ongoing debate for at least since PHP 5.0.  I have no preference
> strong enough to die on that hill, though, so whatever voters are willing
> to go for I'm good with.
>
> Anyone care enough to offer a bikeshed color?
>
> --Larry Garfield
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #110880 — Larry Garfield — 2020-07-08T15:09:05+00:00

URL: https://externals.io/message/110711#110880 · In reply to: #110870

> There are some problem by using double back slash for PHP namespace?
> 
> Eg. Instead of \PHP\String be just \\String.

Currently that's a syntax error, and I don't think we have time to change it before the code freeze even if we could all agree to do so.

--Larry Garfield

---

## #110889 — Dan Ackroyd — 2020-07-09T08:51:12+00:00

URL: https://externals.io/message/110711#110889 · In reply to: #110861

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

---

## #110892 — Rowan Tommins — 2020-07-09T11:55:56+00:00

URL: https://externals.io/message/110711#110892 · In reply to: #110889

> On Tue, 7 Jul 2020 at 15:47, Larry Garfield <larry@garfieldtech.com>
> wrote:
> > […]
>
> 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:
> > […]
>
> 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]

---

## #110901 — Larry Garfield — 2020-07-09T17:03:41+00:00

URL: https://externals.io/message/110711#110901 · In reply to: #110892

> 
> 
> > […]
> 
> 
> 
> 
> 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.

> > […]
> 
> 
> 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.
> 
> 
> > […]

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

---

## #110902 — Derick Rethans — 2020-07-09T17:14:09+00:00

URL: https://externals.io/message/110711#110902 · In reply to: #110892

> 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

---

## #110904 — Rowan Tommins — 2020-07-09T18:00:25+00:00

URL: https://externals.io/message/110711#110904 · In reply to: #110902

> 
>
> > […]
>
> 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]

---

## #110911 — Nikita Popov — 2020-07-10T08:54:21+00:00

URL: https://externals.io/message/110711#110911 · In reply to: #110861

On Tue, Jul 7, 2020 at 4:47 PM 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?
>
> 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

---

## #110917 — Larry Garfield — 2020-07-10T14:02:26+00:00

URL: https://externals.io/message/110711#110917 · In reply to: #110911

> On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
> 
> > […]
> 
> 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:
> 
> > […]
> 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

---

## #110918 — Dan Ackroyd — 2020-07-10T14:05:26+00:00

URL: https://externals.io/message/110711#110918 · In reply to: #110901

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

---

## #110927 — Mark Randall — 2020-07-10T17:06:08+00:00

URL: https://externals.io/message/110711#110927 · In reply to: #110911

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

---

## #111054 — Larry Garfield — 2020-07-16T21:42:06+00:00

URL: https://externals.io/message/110711#111054

After some discussion, the namespacing proposal has been again updated.  Two major changes:

1) Only engine code goes in \PHP.  There's a separate \Ext namespace for extensions, whether bundled or PECL.

2) It establishes that an index will be maintained on the Wiki listing what namespaces are already claimed.

https://wiki.php.net/rfc/php_namespace_policy

This is probably (I hope) the final edit of consequence before voting.  Speak now or forever hold your peace. :-)

--Larry Garfield

---

## #111055 — Levi Morrison via internals — 2020-07-17T01:58:27+00:00

URL: https://externals.io/message/110711#111055 · In reply to: #111054

>
> After some discussion, the namespacing proposal has been again updated.  Two major changes:
>
> 1) Only engine code goes in \PHP.  There's a separate \Ext namespace for extensions, whether bundled or PECL.
>
> 2) It establishes that an index will be maintained on the Wiki listing what namespaces are already claimed.
>
> https://wiki.php.net/rfc/php_namespace_policy
>
> This is probably (I hope) the final edit of consequence before voting.  Speak now or forever hold your peace. :-)

Chiming in to formally oppose `\Ext`. I don't think it holds much
value for a few reasons:

  1. If all extensions are in the same namespace then they have to
work out conflicts between themselves anyway. This would not have
helped mongo and mongodb, for instance, nor memcache and memcached.
  2. I don't think this is solving any problems, really:
    - Code can move from PHP land to an extension and back again.
Should the namespace change just because it moved one way or the
other? I vote no.
    - It's more typing for... what gain, exactly?

I'm strongly in the "make namespace short and flat" camp. Deeply
nested namespaces make more sense when you need to distinguish between
projects within a company, for a contrived example
`Amazon\WebServices\SDK`. I can see there being multiple projects with
Amazon, and I can see there being multiple WebServices projects.
Removing a namespace segment doesn't make a lot of sense either,
except for perhaps collapsing the first two to `AWS` but this is just
another point to my short and flat camp. This deeply nested company
organization is not the territory we are in as a project, so we should
keep it simple and keep our namespace short and simple.

---

## #111056 — Mark Randall — 2020-07-17T03:28:50+00:00

URL: https://externals.io/message/110711#111056 · In reply to: #111055

>    2. I don't think this is solving any problems, really:
>      - Code can move from PHP land to an extension and back again.
> Should the namespace change just because it moved one way or the
> other? I vote no.

This is not what the RFC proposes. The point of \Ext is that there would 
be no need to rename them when moving in or out of core.




> I'm strongly in the "make namespace short and flat" camp. Deeply
> nested namespaces make more sense when you need to distinguish between
> projects within a company, for a contrived example
> `Amazon\WebServices\SDK`. I can see there being multiple projects with
> Amazon, and I can see there being multiple WebServices projects.
> Removing a namespace segment doesn't make a lot of sense either,
> except for perhaps collapsing the first two to `AWS` but this is just
> another point to my short and flat camp. This deeply nested company
> organization is not the territory we are in as a project, so we should
> keep it simple and keep our namespace short and simple.

How flat would you want it to be? This RFC proposes 1 level before the 
name of the feature, either PHP or Ext depending on its location. The 
purpose of that one level is to avoid extensions trampling into multiple 
userspace naming areas.

Mark Randall

---

## #111057 — Levi Morrison via internals — 2020-07-17T03:49:48+00:00

URL: https://externals.io/message/110711#111057

>
> 
> > […]
>
> This is not what the RFC proposes. The point of \Ext is that there would
> be no need to rename them when moving in or out of core.

This is not quite the same. I said it moves from _userland_ aka PHP
code, to an _extension_ aka C code. I oppose `Ext` in both case.

> > […]
>
> How flat would you want it to be? This RFC proposes 1 level before the
> name of the feature, either PHP or Ext depending on its location. The
> purpose of that one level is to avoid extensions trampling into multiple
> userspace naming areas.

There is no need to separate between _extensions_ and _userland_ code.
I believe this very premise is flawed.

I don't care to debate it. I will just vote no.

---

## #111058 — Mark Randall — 2020-07-17T03:55:40+00:00

URL: https://externals.io/message/110711#111058 · In reply to: #111057

> I don't care to debate it. I will just vote no.

Fair enough, however the point of the internals mailing list and 
discussion period is to debate the RFCs :-)

---

## #111059 — Lester Caine — 2020-07-17T08:23:49+00:00

URL: https://externals.io/message/110711#111059 · In reply to: #111054

> After some discussion, the namespacing proposal has been again updated.  Two major changes:
> 
> 1) Only engine code goes in \PHP.  There's a separate \Ext namespace for extensions, whether bundled or PECL.

 From RFC ...
" This RFC does NOT propose moving any existing code into the \PHP 
namespace at this time. That may be done by future RFCs if desired, 
under their own votes. This is a “policy document” only. "

So does that also apply to \Ext? Currently the selection of extensions 
is flexible and most distributions allow the easy repackaging of just 
what is available. Creating a 'core' set off extensions under \PHP is 
essentially saying 'you will make these available' while \Ext is a 
second class citizen? Personally I think every package even if relegated 
to PECL deserves to be under \PHP or alternately ONLY the essential core 
engine components go under \PHP and everything else is \Ext

> 2) It establishes that an index will be maintained on the Wiki listing what namespaces are already claimed.
> https://wiki.php.net/rfc/php_namespace_policy
> This is probably (I hope) the final edit of consequence before voting.  Speak now or forever hold your peace.:-)

Many of the 'exotic' functions such as 'reflection' are not essential 
for writing good code, so a core \PHP which defines an essential working 
set of functions does make sense. What HAS been lost is the development 
of better extensions such as a \Ext\String or \Ext|Array extension that 
is more 'object orientated' while leaving the legacy functions wrapped 
in \PHP ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

---

Next page: https://externals.io/message/110711.md?page=2