Hi Nikita Popov,
The question of namespaces in the stdlib has been coming up a lot recently,
so I'd like to present my own stab at resolving this question:https://wiki.php.net/rfc/namespaces_in_bundled_extensions
Relative to a number of previous (declined) proposals, the main difference
is that I do not propose a top-level "PHP" vendor namespace, and instead
recommend the use of "ExtName", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.
Both of the namespacing RFCs have been announced for over 3 weeks and I don't think I've
seen any new discussion since then.
Are any updates planned? When will voting on the namespacing RFC(s) start?
(I had some stdlib RFCs/RFC ideas I was postponing since February to avoid interfering with the namespacing discussion)
Thanks,
Tyson
On Fri, Mar 19, 2021 at 3:04 PM tyson andre tysonandre775@hotmail.com
wrote:
Hi Nikita Popov,
The question of namespaces in the stdlib has been coming up a lot
recently,
so I'd like to present my own stab at resolving this question:https://wiki.php.net/rfc/namespaces_in_bundled_extensions
Relative to a number of previous (declined) proposals, the main
difference
is that I do not propose a top-level "PHP" vendor namespace, and instead
recommend the use of "ExtName", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.Both of the namespacing RFCs have been announced for over 3 weeks and I
don't think I've
seen any new discussion since then.
Are any updates planned? When will voting on the namespacing RFC(s) start?
(I had some stdlib RFCs/RFC ideas I was postponing since February to avoid
interfering with the namespacing discussion)
I'd love to have some more feedback on this RFC before opening voting.
There has been a lot of discussion beforehand, but only a couple responses
to this RFC...
Regards,
Nikita
I'd love to have some more feedback on this RFC before opening voting.
There has been a lot of discussion beforehand, but only a couple responses
to this RFC...
I very much like this pragmatic approach, which also matches most of the
already existing extensions using namespaces. Thank you!
--
Christoph M. Becker
The question of namespaces in the stdlib has been coming up a lot recently,
so I'd like to present my own stab at resolving this question:https://wiki.php.net/rfc/namespaces_in_bundled_extensions
Relative to a number of previous (declined) proposals, the main difference
is that I do not propose a top-level "PHP" vendor namespace, and instead
recommend the use of "ExtName", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.Both of the namespacing RFCs have been announced for over 3 weeks and I don't think I've
seen any new discussion since then.
Are any updates planned? When will voting on the namespacing RFC(s) start?
(I had some stdlib RFCs/RFC ideas I was postponing since February to avoid interfering with the namespacing discussion)I'd love to have some more feedback on this RFC before opening voting. There has been a lot of discussion beforehand, but only a couple responses to this RFC...
I didn't plan to suggest changing the direction of the RFC, so I didn't have much to say.
I guess it's an improvement from a user perspective and that splitting core/PECL/composer namespacing wouldn't make much sense,
especially with the ability to polyfill most core functionality in composer packages (especially with PHP providing FFI, low level socket/stream code, etc).
For something like https://wiki.php.net/rfc/cachediterable I'd still be faced with the namespacing choice among multiple options if this passed,
but choosing names for everything is out of the scope of this RFC.
-
iterable\CachedIterable
would be the most likely, although it's also in some ways a datastructure - For SPL, e.g. for a new Map type or existing classes such as SplObjectStorage,
there'd still be a number of different names such asDataStructure\Map
orCollections\Map
(DS is already used by an independent PECL) - "When adding new symbols to existing extensions, it is more important to be consistent with existing symbols than to follow the namespacing guidelines."
raises the question of whether existing iterables should be aliased to a namespace around the same time - 5 years from now we may have a different group of active voters, so if this passed with low voting turnout
I'm not sure if there'd still be arguments over the choice to use/not use a namespace.
For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable it'd help if there was known community consensus (i.e. the vote on namespaces in bundled extensions finished)
I didn't notice before, but I assume you'd still planned to summarize feedback so far in a discussion section before opening https://wiki.php.net/rfc/namespaces_in_bundled_extensions
For https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
use Array;
and use String;
are currently syntax errors for the unexpected token "array".
That could be fixed in the parser by adding a special case for namespace uses,
especially now that T_NAMESPACED_NAME now allows string\contains
to be used without a syntax error.
One possible concern is what would happen if PHP implemented new functionality that overlapped with a fairly well-known PECL/Composer package.
E.g. if there was already a FooDB\Client in a composer/PECL package, and an independent implementation was later added to php-src,
there'd potentially be conflicting names.
Being able to implement PHP\FooDB\Client
would avoid that ambiguity
- Then again, other programming languages such as Python have no issue with that, so never mind.
FooDBClient\ or Foo\ or something could probably be used.
All symbols defined in the extension should be part of the top-level namespace or a sub-namespace.
This should be clarified - do you mean the extension's top-level namespace (e.g. OpenSSL) instead of the global namespace? I assume the former.
Regards,
Tyson
On Mon, Apr 5, 2021 at 8:05 PM tyson andre tysonandre775@hotmail.com
wrote:
The question of namespaces in the stdlib has been coming up a lot
recently,
so I'd like to present my own stab at resolving this question:https://wiki.php.net/rfc/namespaces_in_bundled_extensions
Relative to a number of previous (declined) proposals, the main
difference
is that I do not propose a top-level "PHP" vendor namespace, and
instead
recommend the use of "ExtName", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.Both of the namespacing RFCs have been announced for over 3 weeks and I
don't think I've
seen any new discussion since then.
Are any updates planned? When will voting on the namespacing RFC(s)
start?
(I had some stdlib RFCs/RFC ideas I was postponing since February to
avoid interfering with the namespacing discussion)I'd love to have some more feedback on this RFC before opening voting.
There has been a lot of discussion beforehand, but only a couple responses
to this RFC...I didn't plan to suggest changing the direction of the RFC, so I didn't
have much to say.
I guess it's an improvement from a user perspective and that splitting
core/PECL/composer namespacing wouldn't make much sense,
especially with the ability to polyfill most core functionality in
composer packages (especially with PHP providing FFI, low level
socket/stream code, etc).For something like https://wiki.php.net/rfc/cachediterable I'd still be
faced with the namespacing choice among multiple options if this passed,
but choosing names for everything is out of the scope of this RFC.
iterable\CachedIterable
would be the most likely, although it's also
in some ways a datastructure- For SPL, e.g. for a new Map type or existing classes such as
SplObjectStorage,
there'd still be a number of different names such asDataStructure\Map
orCollections\Map
(DS is already used by an independent PECL)- "When adding new symbols to existing extensions, it is more important to
be consistent with existing symbols than to follow the namespacing
guidelines."
raises the question of whether existing iterables should be aliased to a
namespace around the same time- 5 years from now we may have a different group of active voters, so if
this passed with low voting turnout
I'm not sure if there'd still be arguments over the choice to use/not
use a namespace.
Right. I think the two main things this RFC establishes is that a) yes, it
is okay to use a namespace and b) that namespace should not have a PHP
prefix. That still leaves you with quite a lot of different choices, but I
think it removes the two most contentious issues from further discussion.
For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable
it'd help if there was known community consensus (i.e. the vote on
namespaces in bundled extensions finished)I didn't notice before, but I assume you'd still planned to summarize
feedback so far in a discussion section before opening
https://wiki.php.net/rfc/namespaces_in_bundled_extensionsFor
https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
use Array;
anduse String;
are currently syntax errors for the
unexpected token "array".
That could be fixed in the parser by adding a special case for namespace
uses,
especially now that T_NAMESPACED_NAME now allowsstring\contains
to be
used without a syntax error.
Yes, those particular examples are somewhat problematic. I believe my
original version of https://wiki.php.net/rfc/namespaced_names_as_token also
allowed those "use" statements, so this isn't a technical problem for a new
PHP version that decides to use them. It would be a problem for polyfills
though, which is why we'd probably want to go for some other naming here.
Say Str\contains instead of String\contains. (Worth noting that this issue
also exists with "PHP\Array" before PHP 8.0, so it's not a problem that
presence of a vendor prefix would resolve, outside specific cases.)
One possible concern is what would happen if PHP implemented new
functionality that overlapped with a fairly well-known PECL/Composer
package.
E.g. if there was already a FooDB\Client in a composer/PECL package, and
an independent implementation was later added to php-src,
there'd potentially be conflicting names.
Being able to implementPHP\FooDB\Client
would avoid that ambiguity
- Then again, other programming languages such as Python have no issue
with that, so never mind.
FooDBClient\ or Foo\ or something could probably be used.
Right. For an existing PECL extension it would be best to just bundle it
instead of implementing a new one (even though that seems to be in fashion
recently...) But for the more general question, we should try to be
courteous and avoid collisions with important known libraries/extensions.
There's usually enough leeway with naming. If worst comes to worst, you can
always pull a mysql + mysqli :)
All symbols defined in the extension should be part of the top-level
namespace or a sub-namespace.This should be clarified - do you mean the extension's top-level
namespace (e.g. OpenSSL) instead of the global namespace? I assume the
former.
Indeed, that's what I meant. I've added the extra word.
Regards,
Nikita
On Mon, Apr 5, 2021 at 8:05 PM tyson andre tysonandre775@hotmail.com
wrote:The question of namespaces in the stdlib has been coming up a lot
recently,
so I'd like to present my own stab at resolving this question:https://wiki.php.net/rfc/namespaces_in_bundled_extensions
Relative to a number of previous (declined) proposals, the main
difference
is that I do not propose a top-level "PHP" vendor namespace, and
instead
recommend the use of "ExtName", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.Both of the namespacing RFCs have been announced for over 3 weeks and I
don't think I've
seen any new discussion since then.
Are any updates planned? When will voting on the namespacing RFC(s)
start?
(I had some stdlib RFCs/RFC ideas I was postponing since February to
avoid interfering with the namespacing discussion)I'd love to have some more feedback on this RFC before opening voting.
There has been a lot of discussion beforehand, but only a couple responses
to this RFC...I didn't plan to suggest changing the direction of the RFC, so I didn't
have much to say.
I guess it's an improvement from a user perspective and that splitting
core/PECL/composer namespacing wouldn't make much sense,
especially with the ability to polyfill most core functionality in
composer packages (especially with PHP providing FFI, low level
socket/stream code, etc).For something like https://wiki.php.net/rfc/cachediterable I'd still be
faced with the namespacing choice among multiple options if this passed,
but choosing names for everything is out of the scope of this RFC.
iterable\CachedIterable
would be the most likely, although it's also
in some ways a datastructure- For SPL, e.g. for a new Map type or existing classes such as
SplObjectStorage,
there'd still be a number of different names such as
DataStructure\Map
orCollections\Map
(DS is already used by an
independent PECL)- "When adding new symbols to existing extensions, it is more important
to be consistent with existing symbols than to follow the namespacing
guidelines."
raises the question of whether existing iterables should be aliased to
a namespace around the same time- 5 years from now we may have a different group of active voters, so if
this passed with low voting turnout
I'm not sure if there'd still be arguments over the choice to use/not
use a namespace.Right. I think the two main things this RFC establishes is that a) yes, it
is okay to use a namespace and b) that namespace should not have a PHP
prefix. That still leaves you with quite a lot of different choices, but I
think it removes the two most contentious issues from further discussion.For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable
it'd help if there was known community consensus (i.e. the vote on
namespaces in bundled extensions finished)I didn't notice before, but I assume you'd still planned to summarize
feedback so far in a discussion section before opening
https://wiki.php.net/rfc/namespaces_in_bundled_extensionsFor
https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
use Array;
anduse String;
are currently syntax errors for the
unexpected token "array".
That could be fixed in the parser by adding a special case for namespace
uses,
especially now that T_NAMESPACED_NAME now allowsstring\contains
to be
used without a syntax error.Yes, those particular examples are somewhat problematic. I believe my
original version of https://wiki.php.net/rfc/namespaced_names_as_token
also allowed those "use" statements, so this isn't a technical problem for
a new PHP version that decides to use them. It would be a problem for
polyfills though, which is why we'd probably want to go for some other
naming here. Say Str\contains instead of String\contains. (Worth noting
that this issue also exists with "PHP\Array" before PHP 8.0, so it's not a
problem that presence of a vendor prefix would resolve, outside specific
cases.)One possible concern is what would happen if PHP implemented new
functionality that overlapped with a fairly well-known PECL/Composer
package.
E.g. if there was already a FooDB\Client in a composer/PECL package, and
an independent implementation was later added to php-src,
there'd potentially be conflicting names.
Being able to implementPHP\FooDB\Client
would avoid that ambiguity
- Then again, other programming languages such as Python have no issue
with that, so never mind.
FooDBClient\ or Foo\ or something could probably be used.Right. For an existing PECL extension it would be best to just bundle it
instead of implementing a new one (even though that seems to be in fashion
recently...) But for the more general question, we should try to be
courteous and avoid collisions with important known libraries/extensions.
There's usually enough leeway with naming. If worst comes to worst, you can
always pull a mysql + mysqli :)All symbols defined in the extension should be part of the top-level
namespace or a sub-namespace.This should be clarified - do you mean the extension's top-level
namespace (e.g. OpenSSL) instead of the global namespace? I assume the
former.Indeed, that's what I meant. I've added the extra word.
Regards,
Nikita
I've now added an explicit section regarding namespace collisions to the
RFC, and tweaked some of the examples (String\contains, Array\contains).
If there's no further feedback I'll open voting soon.
Regards,
Nikita
All symbols defined in the extension should be part of the top-level
namespace or a sub-namespace.This should be clarified - do you mean the extension's top-level
namespace (e.g. OpenSSL) instead of the global namespace? I assume the
former.Indeed, that's what I meant. I've added the extra word.
Regards,
NikitaI've now added an explicit section regarding namespace collisions to the
RFC, and tweaked some of the examples (String\contains, Array\contains).If there's no further feedback I'll open voting soon.
Regards,
Nikita
Thanks, Nikita.
Only one remaining question/comment/request from my end: In the "Migration of existing symbols" section, can you clarify explicitly that this RFC does not preclude such migration proposals in the future? The reading of the previous section could easily be taken in the future to mean "and existing code is stuck where it is forever", even if that's not the intent.
Eg, it's fine that the RFC does not propose mass-migrating all str_* functions to Str*, but if someone in the future proposes doing that migration (with shims/aliases), that should be able to stand on its own merits. I want to preempt anyone trying to respond in such a discussion "the original RFC said they wouldn't move, so you can't do this migration RFC now," because I'm sure someone will try to use that angle in the future should such a proposal appear. :-)
Thanks again.
--Larry Garfield
On Wed, Apr 14, 2021 at 5:39 PM Larry Garfield larry@garfieldtech.com
wrote:
All symbols defined in the extension should be part of the top-level
namespace or a sub-namespace.This should be clarified - do you mean the extension's top-level
namespace (e.g. OpenSSL) instead of the global namespace? I assume the
former.Indeed, that's what I meant. I've added the extra word.
Regards,
NikitaI've now added an explicit section regarding namespace collisions to the
RFC, and tweaked some of the examples (String\contains, Array\contains).If there's no further feedback I'll open voting soon.
Regards,
NikitaThanks, Nikita.
Only one remaining question/comment/request from my end: In the "Migration
of existing symbols" section, can you clarify explicitly that this RFC does
not preclude such migration proposals in the future? The reading of the
previous section could easily be taken in the future to mean "and existing
code is stuck where it is forever", even if that's not the intent.Eg, it's fine that the RFC does not propose mass-migrating all str_*
functions to Str*, but if someone in the future proposes doing that
migration (with shims/aliases), that should be able to stand on its own
merits. I want to preempt anyone trying to respond in such a discussion
"the original RFC said they wouldn't move, so you can't do this migration
RFC now," because I'm sure someone will try to use that angle in the future
should such a proposal appear. :-)
Yeah, I definitely didn't want to imply that such a migration can't happen
in the future. I've now moved this into a "Future Scope" section (
https://wiki.php.net/rfc/namespaces_in_bundled_extensions#future_scope).
Hopefully that makes it clear that a followup RFC can deal with this
question.
Regards,
Nikita