[RFC] PHP Namespace Policy

4 years ago by Mark Randall — view source

unread

Greetings,

I would like to re-open the discussion on properly reserving the \PHP
namespace for the use of the engine and its core extensions.

Rather than seek to demand everything be moved into namespaces, I have
instead written this RFC as something that would form a policy
guideline for future development of the engine and those extensions
which are directly managed by internals.

At present, the accepted style is to "fake" a namespace by prefixing
symbols with Php.

As internals "claims" the top level namespace, this effectively means
that all userland code must exist in its own namespace, which is
indeed how almost all modern userland code is written, which if
anything this proves the benefit of namespacing.

In effect, this is both demanding a particular style, while choosing
not to use it ourselves.

Furthermore, based on the common understanding that a namespace owns
and is responsible for all of its descendants, our current arrangement
is that all code belongs to PHP and that internals using any
namespaces at all could lead to a legitimate collision.

Finally, the \PHP namespace itself IS already noted in the
documentation to be reserved.
https://www.php.net/manual/en/language.namespaces.rationale.php

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

This RFC would formalise that notice, and give notice to internals
that the use of \PHP was permitted and encouraged.

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

--
Mark Randall

4 years ago by Derick Rethans — view source

unread

Hi Mark,

I would like to re-open the discussion on properly reserving the \PHP
namespace for the use of the engine and its core extensions.

I will be voting no against this. The RFC states:

By design this RFC does NOT propose moving anything existing into
the \PHP namespace at this time, only that the policy is set that it
is the preferred mechanism for future development.

This will mean that in a future version of PHP, some things will live in
a \PHP namespace, and others, such as DateTimeImmutable or Directory do
not. We should not be introducing inconsistencies.

It also says:

 \PHP (must be empty except for other namespaces)

Which means new additions to PHP 8, such as a potential PhpAttribute,
now would have been \PHP\Engine\Attribute, while we already have
PhpToken. That is another inconsistency that we don't need.

I would potentially be OK with having both \PHP\Token and
\PHP\Attribute, as in PHP 8 these engine related classes are being
introduced for a first time (as far as I am aware).

cheers,
Derick

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

4 years ago by Mark Randall — view source

unread

This will mean that in a future version of PHP, some things will live in
a \PHP namespace, and others, such as DateTimeImmutable or Directory do
not. We should not be introducing inconsistencies.

It notes that it should be the preferred method for new feature
development, and intentionally stops short of requiring it, to provide
plenty of room for leeway in cases like this where there is an obvious
benefit to keeping features aligned.

Which means new additions to PHP 8, such as a potential PhpAttribute,
now would have been \PHP\Engine\Attribute, while we already have
PhpToken. That is another inconsistency that we don't need.

I would argue that both these two great new features would benefit from
an additional level, unless of course we can guarentee that we would
never introduce anything else into PHP called token, or attribute, at
which point we are back to square one, a problem which can be almost all
together avoided by adding a "feature" specific namespace under \PHP.

--
Mark Randall
marandall@php.net

4 years ago by Dan Ackroyd — view source

unread

Rather than seek to demand everything be moved into namespaces, I have
instead written this RFC as something that would form a policy
guideline for future development of the engine and those extensions
which are directly managed by internals.

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

Hi Mark,

Everything is a trade-off.

Putting core functions under a namespace makes those core functions
harder to use, as people would need to 'use' those functions to make
them available in their current namespace.

Even assuming the reasons in the RFC are correct, the tradeoff between
them and 'making core functions harder to use' does not seem a great
tradeoff to make.

Another benefit of having core PHP symbols in the root namespace is
that it means we can avoid having the discussion of what the namespace
naming rules should be. Again, the tradeoff of having to spend time on
that discussion of how to name things vs a possible small benefit of
having new symbols under a namespace, seems a bad tradeoff.

Is there anything you want to add to the RFC to change that view?

This RFC would establish the protocol for a registry, upon
which internals and core extension authors can, as part of their RFC, ...

This is a direct suggestion of how to slow down productivity from the
CIA "Simple sabotage field manual"*:

(11) General interference with Organizations and Production
(b) Managers and supervisors
(13) Multiply the procedures and clearances involved in issuing
instructions, pay checks, and so on. See that three people have to
approve everything where one would do.

Even if you think namespaces might help a little, I don't think
introducing a new procedure for RFCs would be worth that cost.

cheers
Dan
Ack

"Simple sabotage field manual" -
https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf
Note, the CIA still had the name OSS when published.

4 years ago by Mark Randall — view source

unread

Another benefit of having core PHP symbols in the root namespace is
that it means we can avoid having the discussion of what the namespace
naming rules should be. Again, the tradeoff of having to spend time on
that discussion of how to name things vs a possible small benefit of
having new symbols under a namespace, seems a bad tradeoff.

Dan,

I see this being as simple as the RFC author stating that they intend to
use a specific namespace such as:

\PHP\Tokenizer

Followed by updating a wiki page once it's been approved to list the
namespace and the RFC which approved it.

In that respect it would be no different than arguing over any other
name which can already happen.

Mark Randall
marandall@php.net

4 years ago by Remi Collet — view source

unread

Le 15/04/2020 à 13:21, Mark Randall a écrit :

Greetings,

I would like to re-open the discussion on properly reserving the \PHP
namespace for the use of the engine and its core extensions.

What does that mean for PECL extension ?

If they have to use another namespace,
sorry, but I will vote NO, as this doesn't make any sense

Extension (pecl or other) can be include in core later
or core extension dropped and move to pecl.

I rather think than C ext should use no namespace

Remi

4 years ago by Mark Randall — view source

unread

Le 15/04/2020 à 13:21, Mark Randall a écrit :
Extension (pecl or other) can be include in core later
or core extension dropped and move to pecl.

Quoting the RFC:

Once approved, a namespace that is a child of \PHP will remain
exclusively for the originally assigned purpose, even if the associated
code is moved out of core, unless a 2/3rds vote is held to withdraw that
namespace.

By design this RFC does NOT propose moving anything existing into the
\PHP namespace at this time, nor does it REQUIRE future development uses
it, only that the policy is set that it is the preferred mechanism for
future development where suitable to do so.

4 years ago by Andrea Faulds — view source

unread

Hi Mark,

Mark Randall wrote:

As internals "claims" the top level namespace, this effectively means
that all userland code must exist in its own namespace, which is
indeed how almost all modern userland code is written, which if
anything this proves the benefit of namespacing.

Yes, post-5.3 PHP internals has essentially claimed the \ namespace for
itself by inaction. Is that a bad thing? It makes all new internal
functions and classes easy to access.

In effect, this is both demanding a particular style, while choosing
not to use it ourselves.

Sure, but your proposal would have us essentially be inconsistent about
using namespaces, as 99% of internal functions, classes and constants
would still be un-namespaced.

Furthermore, based on the common understanding that a namespace owns
and is responsible for all of its descendants, our current arrangement
is that all code belongs to PHP and that internals using any
namespaces at all could lead to a legitimate collision.

This feels like reaching to me. Yes, there is an established convention
for namespaces in userland, but as you already acknowledged, internals
isn't following that convention. I don't think anyone who has some
familiarity with PHP would notice all internals stuff is in \ and
conclude that PHP 8.2 is going to add classes beginning with \Symfony\
or something — after all, wouldn't that mean all projects with a
history predating PHP 5.3 also own all namespaces?

I think this proposal would create more inconsistency (99% of classes in
, some classes in \PHP) for negligible benefit.

Regards,
Andrea

3 years ago by Mark Randall — view source

unread

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

Just an update in light of the two different RFCs.

Having chatted with the other RFC authors in R11, rather than racing to
see who can get their RFC to vote first, it seems like there's room for
both.

Vote 1 would be the other RFC which would be something along the lines of:

"Mandate the use of \PHP for future internal tightly-bound components"

If vote 1 were passed, the next vote would be on this RFC, and would
cover policy on namespace usage and would be something like:

"The \PHP namespace must remain empty, except for child namespaces".

This would be to prevent the problem of colliding internals symbols
throughout the rest of PHP's maintained lifespan (such as what if there
was something else added to core called Token).

Vote 3 would mandate only autoloadable classes / interfaces / traits etc
etc were used, allowing userland polyfills (where sensible) to provide a
route for users to begin using newer API functionality without an
immediate upgrade.

Votes 1 and 2 passing would put us on a pretty good course for long-term
sanity.

Vote 1 passing and 2 failing would result in part of the problem just
being moved to \PHP and exposing us to symbol collision further down the
line.

If vote 1 failed, we would have to consider if this RFC would pass with
its tigher constraints.

The question is, how would we vote on extra uses for PHP.

While the alternative RFC mandates its use for tightly coupled, I think
it makes a lot of sense to add extra things to it, such as re-designed
collections (borg Ds?) in \PHP\Collections in a similar fashion to:

https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=netframework-4.8

Mark Randall

3 years ago by Mark Randall — view source

unread

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

As it has come up a few times, I wanted to provide examples of where
programming languages mount their own standard libraries inside a main
namespace:

Java (java.*)
https://en.wikipedia.org/wiki/Java_Platform,_Standard_Edition

.NET (System.*)
https://docs.microsoft.com/en-us/dotnet/api/system?view=dotnet-plat-ext-3.1

C++ (std::*)
https://en.cppreference.com/w/cpp/header

I would be interested in hearing arguments why such a strategy adopted
with great success by many of the most popular and well-developed
languages, is inappropriate for PHP.

Mark Randall

3 years ago by Michael Morris — view source

unread

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

Just an update in light of the two different RFCs.

Having chatted with the other RFC authors in R11, rather than racing to
see who can get their RFC to vote first, it seems like there's room for
both.

Vote 1 would be the other RFC which would be something along the lines of:

"Mandate the use of \PHP for future internal tightly-bound components"

If vote 1 were passed, the next vote would be on this RFC, and would
cover policy on namespace usage and would be something like:

"The \PHP namespace must remain empty, except for child namespaces".

This would be to prevent the problem of colliding internals symbols
throughout the rest of PHP's maintained lifespan (such as what if there
was something else added to core called Token).

Vote 3 would mandate only autoloadable classes / interfaces / traits etc
etc were used, allowing userland polyfills (where sensible) to provide a
route for users to begin using newer API functionality without an
immediate upgrade.

Votes 1 and 2 passing would put us on a pretty good course for long-term
sanity.

Vote 1 passing and 2 failing would result in part of the problem just
being moved to \PHP and exposing us to symbol collision further down the
line.

If vote 1 failed, we would have to consider if this RFC would pass with
its tigher constraints.

The question is, how would we vote on extra uses for PHP.

While the alternative RFC mandates its use for tightly coupled, I think
it makes a lot of sense to add extra things to it, such as re-designed
collections (borg Ds?) in \PHP\Collections in a similar fashion to:

https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=netframework-4.8

Mark Randall

--

I would like to submit from the peanut gallery of user land. My perspective
here is as a user, not as an internals writer. I also have no formal
training so I can bring that perspective to the table for consideration.
That said, I don't represent anyone but myself.

I've read the talk of how the \PHP namespace should be used and not be
used. I personally think we should slow down and carefully consider what we
can do here, because active assignment of the namespace will have
ramifications for the rest of PHP's life. We have the opportunity to make a
course change, but it won't be easy. And we only really get one good shot
at this.

All of PHP's core functionality is currently in . All of it. That makes
the language easy to pick up and learn, but the functions in that namespace
are, well, idiosyncratic. Are the arguments in (haystack, needle) order or
(needle, haystack). Is the function camelCase or underscore_delimited or
neitherone?

Changing function names and argument orders would lead to BC breaks so
massive people would move away without a transition plan that was
sustainable long term. Namespaces give that opportunity, I think.

So, in steps:

Take the current function roster - all of it - and put it in
\PHP\Legacy. So the formal name of strpos would become
\PHP\Legacy\strpos.
The root namespace would be empty BUT...
An INI directive set globally or per directory can set which namespace
is bound to root. Initially this would be "\PHP\Legacy", so all legacy
code would not have to change - it would run in the new version and find
all of its functionality without incident. This is critical - as this
directive would likely need to stay as is for two majors minimum, possibly
more.

And yes, I'm keenly aware of the scope of this. The RFC system itself
would need to be changed to allow this to be possible since this approach
demands a design be submitted, approved and THEN an implementation written
and approved. Difficult, but not impossible - the W3C does this all the
time. Even with a Design, then implement RFC system in place, I imagine a
full year would be needed just to get the designs down and agreed upon.
The best PHP 8 could do is just lay the foundation for transition outlined
above and not actually include any alternative to \PHP\Legacy

The rest of \PHP\ would be the replacements for the legacy pieces. It
needs to be a designed library with a consistent naming schema and argument
orders, at a minimum. It also needs to be broken up so as not to overwhelm
the developers doing the implementation. We might even end up with some
duplication to satisfy the procedural vs. object oriented camps. The new
functions would also have a freer hand since they are opted into.

Beyond that though I don't really think it's helpful for me to go into more
detail because I'm not a language designer. I know enough to know I don't
know enough to give this subject a thorough vetting at this time (I could
certainly learn). The specifics of implementation though are out of scope -
what is in scope is the mechanism of transition. We have a golden
opportunity here.

I guess what I'm asking is, where do we want to go with this? If we aren't
doing something with the legacy functions as part of this I feel it's just
another layer of confusion and frustration for end users like me. There
has to be a clear rhyme and reason to be putting things into the \PHP
namespace.

Again, since there's nothing there right now we get one shot at this. Once
things start going in there they'll have to be supported in perpetuity. So
let's think very, very carefully, about what goes in and how - please.

3 years ago by Mark Randall — view source

unread

So, in steps:

Take the current function roster - all of it - and put it in
\PHP\Legacy. So the formal name of strpos would become
\PHP\Legacy\strpos.

The root namespace would be empty BUT...

An INI directive set globally or per directory can set which namespace
is bound to root. Initially this would be "\PHP\Legacy", so all legacy
code would not have to change - it would run in the new version and find
all of its functionality without incident. This is critical - as this
directive would likely need to stay as is for two majors minimum, possibly
more.

Thank you for the contribution.

However, such a change would never, ever be accepted. With good reason.

Mark Randall
marandall@php.net

3 years ago by Rowan Tommins — view source

unread

Hi Michael,

Changing function names and argument orders would lead to BC breaks so
massive people would move away without a transition plan that was
sustainable long term. Namespaces give that opportunity, I think.

You're not the first person to suggest this, indeed I've thought of trying to write an FAQ for the list, and this would be on it.

There is some merit to the idea, but there's a snag: just using new names for new versions of things (which is what a new namespace would be) helps machines know which is which, but it doesn't help humans know which is which. Instead of "Does strpos take needle or haystack first?" the user would now have to think "Is this file using the old or new functions? Is one of them called str_pos and the other strpos, and do they take arguments in a different order?"

The general consensus is that the long-term solution is to add new object-oriented APIs, including "scalar objects" (syntax to call methods in strings, integers, etc). That's not necessarily because OO is better, but because it's sufficiently different that it can comfortably sit side by side with the current functions. We might have $haystack->positionOf($needle) or $needle->positionIn($haystack) or both, and strpos would still be available to all programs with the same arguments it's had for 20 years.

Similarly, an OO-based file handling API would give us a chance to design in better error handling so there was no need for the @ operator and lots of ===false checks. That new API is the kind of thing that could live under the \PHP namespace, but the old functions wouldn't need to move anywhere.

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Michael Morris — view source

unread

On Sat, Apr 25, 2020 at 3:28 AM Rowan Tommins rowan.collins@gmail.com
wrote:

Hi Michael,

Changing function names and argument orders would lead to BC breaks so
massive people would move away without a transition plan that was
sustainable long term. Namespaces give that opportunity, I think.

You're not the first person to suggest this, indeed I've thought of trying
to write an FAQ for the list, and this would be on it.

There is some merit to the idea, but there's a snag: just using new names
for new versions of things (which is what a new namespace would be) helps
machines know which is which, but it doesn't help humans know which is
which. Instead of "Does strpos take needle or haystack first?" the user
would now have to think "Is this file using the old or new functions? Is
one of them called str_pos and the other strpos, and do they take arguments
in a different order?"

I'm aware of this pain point, but I have to deal with it when moving
between languages anyway. A project that uses both older and newer
versions of the same function is going to happen regardless of the
namespace it is placed in, and if namespaces aren't used then the names
just keep getting longer and longer.

The general consensus is that the long-term solution is to add new
object-oriented APIs, including "scalar objects" (syntax to call methods in
strings, integers, etc). That's not necessarily because OO is better, but
because it's sufficiently different that it can comfortably sit side by
side with the current functions. We might have
$haystack->positionOf($needle) or $needle->positionIn($haystack) or both,
and strpos would still be available to all programs with the same arguments
it's had for 20 years.

Similarly, an OO-based file handling API would give us a chance to design

in better error handling so there was no need for the @ operator and lots
of ===false checks. That new API is the kind of thing that could live under
the \PHP namespace, but the old functions wouldn't need to move anywhere.

I like these ideas, but they don't address the point I was making

I would like the old "throw it all in" approach to be moved out of \ and
into \PHP\Legacy.
Why? I want \ to be empty. Long term I feel this is the best approach
because it matches nearly all other languages.
Wouldn't that break everything? Yes, which is the reason for a mechanism
to allow the user to configure which namespaces are loaded onto the root.
By default, this will be /PHP/Legacy so that Legacy code will be able to
run unimpeded.

Or is \ itself just going to be legacy? I suppose that could be done, but
functions without a namespace at all irks me.

3 years ago by Rowan Tommins — view source

unread

I would like the old "throw it all in" approach to be moved out of \ and
into \PHP\Legacy.
...
Or is \ itself just going to be legacy? I suppose that could be done

Renaming all the existing functions (and which ones? everything in
PECL?) to PHP\Legacy\foo and then aliasing them back again would just be
adding effort for everybody. If we really got to the stage where every
single function in core had a non-legacy replacement outside the root
namespace, we could just have a setting that "turned off" the versions
in the root namespace. But frankly I can't imagine that ever happening;
it's pretty much the same effort as "let's throw out the language and
start again".

Regards,

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

3 years ago by Michael Morris — view source

unread

So, in steps:

Take the current function roster - all of it - and put it in
\PHP\Legacy. So the formal name of strpos would become
\PHP\Legacy\strpos.

The root namespace would be empty BUT...

An INI directive set globally or per directory can set which namespace
is bound to root. Initially this would be "\PHP\Legacy", so all legacy
code would not have to change - it would run in the new version and find
all of its functionality without incident. This is critical - as this
directive would likely need to stay as is for two majors minimum,
possibly
more.

Thank you for the contribution.

However, such a change would never, ever be accepted. With good reason.

Mark Randall
marandall@php.net

--

What good reason? Because it is hard?

3 years ago by Rowan Tommins — view source

unread

I would be interested in hearing arguments why such a strategy adopted
with great success by many of the most popular and well-developed
languages, is inappropriate for PHP.

To me, the answer to that is quite simple: we have several hundred
functions, and several dozen classes and interfaces, which are not in such
a namespace; and we have millions of lines of code out in the world using
them. So either we need a strong rationale and a concrete plan to move all
of those into the namespace, or we need a consistent policy on what goes in
and what stays out. It wouldn't make much sense, for instance, to have
PHP\str_contains but no plan to move str_replace.

The decisions you can make in version 8 of a language are inevitably
different from those you can make prior to version 1.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Mike Schinkel — view source

unread

To me, the answer to that is quite simple: we have several hundred
functions, and several dozen classes and interfaces, which are not in such
a namespace; and we have millions of lines of code out in the world using
them. So ... we need a consistent policy on what goes in
and what stays out.

How about a simply policy: Newer things go in, older ones stay out?

Check the docs to see which is which if you are unsure, or just let your IDE auto-complete for you.

-Mike

3 years ago by Rowan Tommins — view source

unread

How about a simply policy: Newer things go in, older ones stay out?

Check the docs to see which is which if you are unsure, or just let your IDE auto-complete for you.

So you'd be happy with PHP\str_contains and \str_replace next to each
other indefinitely? Or, more in line with your proposal, a hypothetical
PHP\Iterators\FractallyAwesomeIterator next to \InifiniteIterator,
\LimitIterator, etc? Or did you have some stronger definition of "newer
things" in mind?

I don't really see what such an arbitrary split would gain us, other
than a lot of confusion. Importantly, it wouldn't be following the lead
of the other languages and frameworks you mentioned, which was the
specific point I was responding to.

Regards,

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

3 years ago by Mike Schinkel — view source

unread

So you'd be happy with PHP\str_contains and \str_replace next to each other indefinitely?

Absolutely. The benefits of having a PHP namespace would outweigh the lack of elegance above.

OTOH I'm not sure why we could not have both \str_replace and PHP\str_replace, with a plan to deprecate the former many versions from now.

Or, more in line with your proposal, a hypothetical PHP\Iterators\FractallyAwesomeIterator next to \InifiniteIterator, \LimitIterator, etc? Or did you have some stronger definition of "newer things" in mind?

Newer things === things that come chronologically after an RFC is approved.

If we have to ensure elegance across the entire language it becomes very hard to ever improve it as new things are usually inconsistent with less-elegant prior approaches.

I don't really see what such an arbitrary split would gain us, other than a lot of confusion.

The "arbitrary split" is not what where we would see the gain, that is just an unfortunately inconvenience.

The gain would come from having a PHP namespace where we don't have to worry about naming conflicts in user-land moving forward.

The former is an acceptable tradeoff to gain the latter. IMO anyway. But YMMV.

Importantly, it wouldn't be following the lead of the other languages and frameworks you mentioned, which was the specific point I was responding to.

Did I mention other languages and frameworks? I just wrote the simple reply above saying "newer things go in, older ones stay out."

-Mike

3 years ago by Rowan Tommins — view source

unread

On Apr 27, 2020, at 6:05 PM, Rowan Tommins rowan.collins@gmail.com
wrote:

So you'd be happy with PHP\str_contains and \str_replace next to each
other indefinitely?

Absolutely. The benefits of having a PHP namespace would outweigh the
lack of elegance above.

OK, on that part I simply disagree. One of the biggest complaints about
PHP's standard library is inconsistency; adding more to that by putting
what would feel like a random selection of functions (or classes) in a
namespace is a lot more than "lack of elegance". The benefits, on the other
hand, seem to be a theoretical saving of a one-off cost on the usually slim
chance that the name we choose conflicts with something in userland.

OTOH I'm not sure why we could not have both \str_replace and
PHP\str_replace, with a plan to deprecate the former many versions from now.

Let me quote myself:

So either we need a strong rationale and a concrete plan to move all of
those into the namespace, or we need a consistent policy on what goes in
and what stays out.

IMO neither a policy of "everything new goes in, but nothing moves" nor
"we'll remove the old names in 20 years time" is a workable plan; we need
something a lot more specific than that.

All these prefixes, like PhpAttribute being discussed right now, only
decrease readability.

One prefix doesn't make a trend. "PhpToken" is a different case - it's a
token of PHP source code, so the prefix isn't anything to do with avoiding
name collisions, it's a natural clarification.

To be honest, I'd be perfectly happy with the attributes RFC using the
class name "Attribute", just as we use "Iterator", "Closure", "Exception",
etc, etc. At which point the whole thing's a non-issue.

On the other hand, I'd be fine with a new PHP\Attributes* namespace being
used, but it would be good to have some guidelines on when namespaces are
and aren't going to be used, to avoid us having the debate every time.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Max Semenik — view source

unread

On Tue, Apr 28, 2020 at 11:45 AM Rowan Tommins rowan.collins@gmail.com
wrote:

One prefix doesn't make a trend. "PhpToken" is a different case - it's a
token of PHP source code, so the prefix isn't anything to do with avoiding
name collisions, it's a natural clarification.

There's also SPL, with classes like SplEnum, SplBool, etc.

To be honest, I'd be perfectly happy with the attributes RFC using the
class name "Attribute", just as we use "Iterator", "Closure", "Exception",
etc, etc. At which point the whole thing's a non-issue.

I hope it's not too late to change this before 8.0 is branched?

--
Best regards,
Max Semenik

3 years ago by Rowan Tommins — view source

unread

On Tue, Apr 28, 2020 at 11:45 AM Rowan Tommins rowan.collins@gmail.com
wrote:

One prefix doesn't make a trend. "PhpToken" is a different case - it's a
token of PHP source code, so the prefix isn't anything to do with avoiding
name collisions, it's a natural clarification.

There's also SPL, with classes like SplEnum, SplBool, etc.

Those particular examples are part of an extension which has never made it
out of "experimental" status, but you're right that there are some like
that in core.

To be honest, I've never really understood the concept behind SPL being its
own extension, and I certainly wouldn't look to its naming conventions as
any kind of precedent for future code.

Some parts should probably just be considered "part of the language", and
their names aren't prefixed:

the various Iterators
Countable interface (why is this in SPL, but ArrayAccess not?)
the various Exceptions
class_implements, class_parents, class_uses
iterator_apply, iterator_count, iterator_to_array
ArrayObject (although its value is debatable)

The functions which are prefixed feel like they shouldn't be:

spl_autoload_* (autoloading is a core feature, and using it with
__autoload is now deprecated)
spl_object_hash and spl_object_id (why do these need a prefix if the
class_* functions don't?)

Some of the functionality which is prefixed would be better refined into
more complete APIs as their own extensions:

SplFileInfo, SplFileObject, and SplTempFileObject are an incomplete I/O
system that doesn't work well with the rest of the language
The data structure classes (SplQueue etc) have various problems, and the
new "DS" extension aims to do better

That leaves a handful of things which are prefixed but could probably be
removed without anyone caring:

spl_classes (no idea what the use case for this would be)
SplObserver and SplSubject (anyone proposing these now would probably be
pointed towards PHP-FIG)

To be honest, I'd be perfectly happy with the attributes RFC using the
class name "Attribute", just as we use "Iterator", "Closure", "Exception",
etc, etc. At which point the whole thing's a non-issue.

I hope it's not too late to change this before 8.0 is branched?

As far as I know, there's plenty of time.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Max Semenik — view source

unread

On Mon, Apr 27, 2020 at 11:26 AM Rowan Tommins rowan.collins@gmail.com
wrote:

To me, the answer to that is quite simple: we have several hundred
functions, and several dozen classes and interfaces, which are not in such
a namespace; and we have millions of lines of code out in the world using
them. So either we need a strong rationale and a concrete plan to move all
of those into the namespace, or we need a consistent policy on what goes in
and what stays out.

To me as an end-user, the ability to write readable code is as important as
ability to write code that performs well and is well-tested. All these
prefixes, like PhpAttribute being discussed right now, only decrease
readability. I'd rather have to import \PHP\Attribute or use plain ol'
\Attribute but no prefixes pretty please. I know they can be renamed
locally via use PhpFoo as Foo; but that's a kludge.

It wouldn't make much sense, for instance, to have
PHP\str_contains but no plan to move str_replace.

We don't have to mix namespaced and non-namespaced stuff within the same
area, thus all str* functions should remain unnamespaced, and honestly I
personally don't care if functions are in \ or \PHP. I, however, would
love if no new classes in PHP were prefixed.

--
Best regards,
Max Semenik