Namespaces in Core

a vote which essentially is about adopting
namespaces in core, via new library RFC, is not the way to go about
changing our coding standards. In short, I don't want to the see the
situation where this extension gets merged in to 7.2 (which it should be
:)) only to have someone ask, "what about the 'php' top-level namespace?"
and we all shrug and mutter, "too late" under our breaths.

I would not have noted this if you had not said something. Thank you for doing so.

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

I've been having this same thought lately since looking at the sodium
RFC. Here are my thoughts, centered on the goal of having classes
(and maybe functions?) in a \php{extname}\ namespace hierarchy.

New classes within 7.2 (e.g. \HashContext) to be moved without
concern for BC (e.g. \php\Hash\HashContext)

Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

"Aliasing" could be potentially accomplished in a few ways: 1.
Literally just class_alias(). Put another copy of the
zend_class_entry into the EG(class_table) under a different name. 2.
"Auto-use": Compile-time analysis of classname: "Is it in this list
of BC classes? Implicitly map it." 3. ...?

I like #2 because we can raise compile-time deprecation warnings and
we don't introduce any runtime overhead for most cases.

Obviously, no removal of support for non-namespaced names until AT
LEAST PHP 8.0

This two big unanswered questions for me before I'd put this into an
RFC are: 1. How to achieve BC in the best way 2. What to do about
functions/constants? Instinct says move 'em just like classes.

-Sara

P.S. - wrt libsodium, I think THIS issue is enough for me to come
down on the side of voting non-namespaced to avoid it being an
odd-duck.

0. Discuss what kind of casing we would like to have. The community has
   pretty much settled with CamelCase, however, no need to us to adopt
   that. Having Php is weird but mixing php\SPL is weird too. ;)

Most languages simply use lowercase in their namespace and CamelCase for
class names, e.g.:

php\Integer
php\String
php\Utf8String
php\io\Path
php\io\File
php\io\Directory
php\intl\Locale
php\time\DateTime
php\spl\iterators\RecursiveIteratorIterator

Obviously the same is possible with other rules:

PHP\Integer
PHP\String
PHP\UTF8String
PHP\IO\Path
PHP\IO\File
PHP\IO\Directory
PHP\Intl\Locale
PHP\Time\DateTime
PHP\SPL\Iterators\RecursiveIteratorIterator

I really don't care but lets create a sane standard that is easy to
follow. Let's do this right if at all!

I would start emitting deprecations is PHP 8 and consider removal in PHP
9 only after having a close look at the community how they adopt these
changes.

I would not simply move everything. I would consider every API and try
to clean it up before moving it to namespaces. This is a HUGE junk of
work but unlike PHP 6 and UTF-8 it could be done incrementally without
any concerns about BC or anything. Obviously any API that is considered
fine can be moved and aliased.

This would also be the perfect moment to get nikic's scalar object stuff
in (already illustrated in the example list above). There are many other
things in the pipelines that could help us creating a better Core for
the community, specifically Generics and Enums.

Potential is endless but requires very good planning and alignment and
not a secondary vote due to PECL BC concerns.

I would not have noted this if you had not said something. Thank you
for doing so.

I had this fear and expressed it in the libsodium RFC discussion as
well. That is why I created this discussion. This is an epic decision
for the PHP ecosystem and cannot go unnoticed.

I actually would block that second vote to be honest.

--
Richard "Fleshgrinder" Fussenegger

Hi!

New classes within 7.2 (e.g. \HashContext) to be moved without concern
for BC (e.g. \php\Hash\HashContext)

Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

Do we really need this? I mean, it's not very likely that there's
another RecursiveIteratorIterator in PHP code, and in user code it'd be
namespaced anyway... It just looks like a lot of moving things around
without any visible (at least visible to me) benefit. And given that no
code would be able to use the long name for like 10 years, and even then
why would anybody use long name if short one works.... In general, I
don't see a point. New exts/features - sure.

"Aliasing" could be potentially accomplished in a few ways:

1. Literally just class_alias(). Put another copy of the
   zend_class_entry into the EG(class_table) under a different name.
2. "Auto-use": Compile-time analysis of classname: "Is it in this list
   of BC classes? Implicitly map it."
3. ...?

I like #2 because we can raise compile-time deprecation warnings and
we don't introduce any runtime overhead for most cases.

Obviously, no removal of support for non-namespaced names until AT LEAST PHP 8.0

This two big unanswered questions for me before I'd put this into an RFC are:

1. How to achieve BC in the best way
2. What to do about functions/constants? Instinct says move 'em just
   like classes.

I don't really want \PHP\Core\Constants\E_NOTICE. This looks like
annoying parts of Java too much. I mean, namespaces are great, I use
them every day, they are super-helpful - but that doesn't mean we should
put everything in deep namespaces - especially things that are already
quite fine without them.

--
Stas Malyshev
smalyshev@gmail.com

Just my two cents, but moving and aliasing core PHP
classes/interfaces/functions sounds like an absolutely horrible idea.

My biggest question is WHY would you do that?

Writing user-space code today that uses the global namespace would be
considered extremely bad practice - no one should do that.

If you move everything from the root namespace into new namespaces, what
will that accomplish? You'll have an empty root namespace. But for what?

If nobody else is using the root namespace for anything, how is it
problematic for the language itself to do that?

Besides, it'll be a decade before you can actually remove the root
namespace aliases.

I don't see the point of changing this, at all.

It will lead to inconsistent code and a lot of meaningless overhead for
developers - who, ultimately, stand to gain nothing from this change.

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder php@fleshgrinder.com
wrote:

First: I like namespaces in Core but here me out!

The PHP (case does not matter) would be the proper vendor name to put
Core stuff in, as far as I remember it is also reserved for PHP
functionality. There were also numerous discussions about providing a
cleaned up API there while maintaining backwards compatibility via
aliases and so forth in the non-namespaced Core stuff.

I've been having this same thought lately since looking at the sodium
RFC. Here are my thoughts, centered on the goal of having classes
(and maybe functions?) in a \php{extname}\ namespace hierarchy.

New classes within 7.2 (e.g. \HashContext) to be moved without concern
for BC (e.g. \php\Hash\HashContext)

Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

"Aliasing" could be potentially accomplished in a few ways:

1. Literally just class_alias(). Put another copy of the
   zend_class_entry into the EG(class_table) under a different name.
2. "Auto-use": Compile-time analysis of classname: "Is it in this list
   of BC classes? Implicitly map it."
3. ...?

I like #2 because we can raise compile-time deprecation warnings and
we don't introduce any runtime overhead for most cases.

Obviously, no removal of support for non-namespaced names until AT LEAST
PHP 8.0

This two big unanswered questions for me before I'd put this into an RFC
are:

1. How to achieve BC in the best way
2. What to do about functions/constants? Instinct says move 'em just
   like classes.

-Sara

P.S. - wrt libsodium, I think THIS issue is enough for me to come down
on the side of voting non-namespaced to avoid it being an odd-duck.

I'm strongly against use of the PHP namespace as a blanket namespace
for bundled PHP extensions. The PHP namespace should be used only
for functionality that is actually in some way related to PHP. For
example, the php-ast extension could reasonably be namespaced as
php\ast, as it provides an AST for PHP specifically. Similarly the
tokenizer extension could reasonably be namespaced as php\tokenizer.

Extensions which are not of this type should not live in the PHP
namespace, because they don't have anything specifically to do with
php, apart from the circumstance that they happen to be bundled at
the current point in time. Remember that extension may move from
being bundled to being in PECL and vice versa. If we decide to bundle
the MongoDB extension with php, would we rename the currently used
MongoDB namespace to PHP\MongoDB? If we decided to move it back to
PECL, would the namespace go back to just MongoDB? Or would it stay
PHP\MongoDB, despite not being part of PHP anymore? Should all new
extensions be written with a PHP namespace to account for the
possibility of the extension being bundled with PHP at a later point
in time (even if there are no concrete plans to do so)?

I would answer No to these questions. The namespace MongoDB is not,
as you say, "random", it is meaningful. The namespace PHP is (with
the exceptions in the first paragraph notwithstanding) meaningless
and an artifact of the distribution mechanism, a mechanism which may
change over time.

Regards, Nikita

I thought about this too. I hope you understood that the main reasoning
for me to choose a well known namespace prefix is related to
auto-loading and when to trigger it. The lack of function and constant
auto-loading is a pain and having well known prefixes could solve the
issue since we would never require to even look at the auto-loader if
the namespace starts with php.

Obviously this could be solved for C extensions by allowing them to
register another prefix that should not be auto-loaded: Sodium, MongoDB, ...

Another solution could be to use pecl as their prefix. Although this
couples it to the packaging system which might not be so nice.

Any name that is tied to a company name or something else that makes
things impossible for users to claim (Oracle, MongoDB, ...) is not a
problem. In case of sodium that would probably be Paragon but Sodium
might be fine too.

I am not the judge here, the only thing I want is to ensure that this
does not go unseen and that the potential of breaking something is real
if we choose a random route like some others do. Not saying that we
cannot do it, big ecosystems live without problems doing the same.
However, it should be a very conscious choice and none that is taken
lightly: meaning rules!

--
Richard "Fleshgrinder" Fussenegger

I'm strongly against use of the PHP namespace as a blanket namespace for
bundled PHP extensions. The PHP namespace should be used only for
functionality that is actually in some way related to PHP. For example, the
php-ast extension could reasonably be namespaced as php\ast, as it provides
an AST for PHP specifically. Similarly the tokenizer extension could
reasonably be namespaced as php\tokenizer.

Okay, I'm pickin' up what yer layin' down. Perhaps the question then
should be asked in the other direction:

Given PHP's long history and fanatical dedication to BC, should all
bundled/core classes/functions/constants ALWAYS remain in the root
namespace with a strong advisory to userspace libraries and
applications to use vendor namespacing (which by and large, is
precisely the status quo).

If that makes sense, then that's another reason not to bring Sodium in
as a namespaced library of functions.

-Sara

Hi!

I'm strongly against use of the PHP namespace as a blanket namespace for
bundled PHP extensions. The PHP namespace should be used only for
functionality that is actually in some way related to PHP. For example, the
php-ast extension could reasonably be namespaced as php\ast, as it provides
an AST for PHP specifically. Similarly the tokenizer extension could
reasonably be namespaced as php\tokenizer.

Agree. If we ever need namespace for mongodb extension, it should be
mongodb (choose capitalization to your liking), not php\mongodb - php
should be things that are really php core or specifically deal with
aspects of php as a language - tokenizer, syntax, etc.

And having different NS for extensions in core vs. PECL makes no sense
to me either - especially given that for any user of distros this
distinction is completely immaterial.

Stas Malyshev
smalyshev@gmail.com

First: I like namespaces in Core but here me out!

I'm strongly against use of the PHP namespace as a blanket namespace for
bundled PHP extensions. The PHP namespace should be used only for
functionality that is actually in some way related to PHP. For example, the
php-ast extension could reasonably be namespaced as php\ast, as it provides
an AST for PHP specifically. Similarly the tokenizer extension could
reasonably be namespaced as php\tokenizer.

Extensions which are not of this type should not live in the PHP namespace,
because they don't have anything specifically to do with php, apart from
the circumstance that they happen to be bundled at the current point in
time. Remember that extension may move from being bundled to being in PECL
and vice versa. If we decide to bundle the MongoDB extension with php,
would we rename the currently used MongoDB namespace to PHP\MongoDB? If we
decided to move it back to PECL, would the namespace go back to just
MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP
anymore? Should all new extensions be written with a PHP namespace to
account for the possibility of the extension being bundled with PHP at a
later point in time (even if there are no concrete plans to do so)?

I would answer No to these questions. The namespace MongoDB is not, as you
say, "random", it is meaningful. The namespace PHP is (with the
exceptions in the first paragraph notwithstanding) meaningless and an
artifact of the distribution mechanism, a mechanism which may change over
time.

I very much agree with all of this, and would like to add, that for a
long time it has been documented that PHP owns the top-level
namespace:
http://php.net/manual/en/userlandnaming.rules.php

In any case, a discussion to namespace any existing PHP functionality
should really wait until PHP 8 - and that means, that if we decide to
put Sodium in PHP 7.x, it should not be namespaced out of consistenct
no matter what the RFC result says.

cheers,
Derick

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

I think the Sodium RFC vote is not about namespace but rather about
breaking everything which already use the pecl extension.

Well, it's about both, that's why it's a hard question: in order not to break existing use of the extension, we need to break existing conventions by adding a namespace to core.

I agree with Richard that this should be decided as a general policy, rather than a special exemption for this one extension, and then a fresh debate next time, and next...

Regards,

--
Rowan Collins
[IMSoP]

I'm taking all the No votes spawned by this thread to mean "we
don't want namespaced functions ever".

That would be a bad assumption.

Peter Cowburn wrote:

Slinking in a vote which essentially is about adopting
namespaces in core, via new library RFC, is not the way to go about
changing our coding standards. In short, I don't want to the see the
situation where this extension gets merged in to 7.2 (which it should be
:)) only to have someone ask, "what about the 'php' top-level namespace?"
and we all shrug and mutter, "too late" under our breaths.

aka it should be a separate discussion to whether libsodium should be
included in PHP7.2.

cheers
Dan