[RFC] \PHP namespace usage heuristics

5 years ago by Larry Garfield — view source — reply

unread

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

5 years ago by Rowan Tommins — view source — reply

unread

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]

5 years ago by Larry Garfield — view source — reply

unread

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

5 years ago by Mike Schinkel — view source — reply

unread

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

5 years ago by Larry Garfield — view source — reply

unread

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.

5 years ago by Mark Randall — view source — reply

unread

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

5 years ago by Peter Bowyer — view source — reply

unread

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

5 years ago by Dan Ackroyd — view source — reply

unread

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

5 years ago by Rowan Tommins — view source — reply

unread

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]

5 years ago by Larry Garfield — view source — reply

unread

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

5 years ago by Dan Ackroyd — view source — reply

unread

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.

5 years ago by Derick Rethans — view source — reply

unread

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

5 years ago by Rowan Tommins — view source — reply

unread

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]

5 years ago by Nikita Popov — view source — reply

unread

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

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

5 years ago by Larry Garfield — view source — reply

unread

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

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

Essentially boil down to that.
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

5 years ago by Mark Randall — view source — reply

unread

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.

5 years ago by Michael Wallner — view source — reply

unread

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

5 years ago by Rowan Tommins — view source — reply

unread

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]

5 years ago by Mark Randall — view source — reply

unread

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.

5 years ago by Larry Garfield — view source — reply

unread

Larry Garfield wrote on 07/07/2020 16:46:

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

I guess I'm missing something obvious here, but the RFC says:

Component or sub-component namespaces MUST use CamelCase naming
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

5 years ago by David Rodrigues — view source — reply

unread

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:

Larry Garfield wrote on 07/07/2020 16:46:

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

I guess I'm missing something obvious here, but the RFC says:

Component or sub-component namespaces MUST use CamelCase naming
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

--

To unsubscribe, visit: https://www.php.net/unsub.php

5 years ago by Larry Garfield — view source — reply

unread

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

5 years ago by Larry Garfield — view source — reply

unread

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

Only engine code goes in \PHP. There's a separate \Ext namespace for extensions, whether bundled or PECL.
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

5 years ago by Levi Morrison via internals — view source — reply

unread

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

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

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:

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

5 years ago by Mark Randall — view source — reply

unread

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

5 years ago by Lester Caine — view source — reply

unread

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

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

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

5 years ago by Mark Randall — view source — reply

unread

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

Things under \PHP will be related to either the engine itself, universal
helpers, or PHP as a language.

Everything else, including almost all extensions bundled with php-src,
would go under \Ext

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

Object-orientated styles for strings / arrays provided by the engine
would still go in the root.

5 years ago by Levi Morrison via internals — view source — reply

unread

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.

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.

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.

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.

5 years ago by Mark Randall — view source — reply

unread

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

5 years ago by Rowan Tommins — view source — reply

unread

On Fri, 17 Jul 2020 at 04:50, Levi Morrison via internals <
internals@lists.php.net> wrote:

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.

Hi Levi,

Given this, I presume you also oppose PHP\ for those cases. Do you see
value in using that namespace for code which could never be implemented in
userland, or would you prefer a policy of never using it?

Relatedly, would you be in favour of allowing bundled extensions to use
namespaces in general, with no vendor prefix (as Sodium did in PECL)? Or
should the policy be that there are no namespaces used by the core?

Regards,

Rowan Tommins
[IMSoP]

5 years ago by Larry Garfield — view source — reply

unread

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

Things under \PHP will be related to either the engine itself, universal
helpers, or PHP as a language.

Everything else, including almost all extensions bundled with php-src,
would go under \Ext

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

Object-orientated styles for strings / arrays provided by the engine
would still go in the root.

To provide at little broader perspective:

There's several places that code may live:

The engine
A required bundled extension
An optional/disableable bundled extension
A non-bundled (PECL) extension
User-space

Code sometimes transitions from one home to another; extensions get bundled or unbundled, code is moved from engine to extension or back, user-space code is ported to an extension, etc.

If there are namespaces used at all to indicate "origin" (which of the above categories it falls into), then at least one of those moves is going to also imply renaming. We could debate which one is least impactful, has the best ROI, has the easiest BC handling, etc., but at least one of those boundaries is going to be bumpier than the others.

I personally don't have strong feelings about which boundary we make easier or harder; As long as there is consensus and we have a way to not dump everything in php-src randomly into the global namespace, I'm happy. :-) But any namespace usage is going to imply, well, naming things.

(Just be glad we're not also trying to solve caching at the same time here...)

If namespaces used by php-src do not indicate origin, then they run the sizeable risk of colliding with user-space code, which is exactly what we're trying to avoid.

As far as the depth of the namespace, The three level class name (vendor/component/class.php) is already the nearly universal standard in PHP thanks to PSR-0, PSR-4, and Composer. Really all that's being done here is officially reserving and using PHP (and/or Ext) as the "core vendor," and then following existing conventions. Everything else is already the standard practice across the ecosystem, just said in more formal words with some collaboration processes defined.

--Larry Garfield

5 years ago by Rowan Tommins — view source — reply

unread

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

While you're making a reasonable point, I really wish people would stop
using that particular class as an example, because I don't think the "PHP"
in its name is a " fake namespace" at all - it is an object representing a
token of PHP source code, and thus a PHP token. Even inside a namespace,
there would be an argument for giving it that name.

Regards,

Rowan Tommins
[IMSoP]

5 years ago by Larry Garfield — view source — reply

unread

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

While you're making a reasonable point, I really wish people would stop
using that particular class as an example, because I don't think the "PHP"
in its name is a " fake namespace" at all - it is an object representing a
token of PHP source code, and thus a PHP token. Even inside a namespace,
there would be an argument for giving it that name.

Regards,

Rowan Tommins
[IMSoP]

To use another, then:

\AttributeDeprecated vs \PHP\Attributes\Deprecated

\AttributeJIT vs \PHP\Attributes\JIT

\AttributeMemoize vs \PHP\Attributes\Memoize

There's a very strong potential for php-src to add a number of attribute classes, which would logically have very generic seeming names. Getting those out of the global namespace and into a logical organization would be very good.

--Larry Garfield

[RFC] \PHP namespace usage heuristics

Regards,

Regards,

Regards,

-- Lester Caine - G8HFL

Regards,

Regards,

Regards,

--
Lester Caine - G8HFL