Hi internals,
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.
Regards,
Nikita
Thank you for this RFC, Nikita. This is a necessary first step in the right
direction.
Even though this is out of scope for this RFC, I hope that moving standard
functions to namespaces will be an opportunity to fix inconsistencies in
parameter order, like:
array_map($callback, array)
array_filter($array, $callback)
and not just an alias under a namespace!
— Benjamin
Hi internals,
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.Regards,
Nikita
On Fri, Feb 26, 2021 at 12:18 PM Benjamin Morel benjamin.morel@gmail.com
wrote:
Thank you for this RFC, Nikita. This is a necessary first step in the right
direction.Even though this is out of scope for this RFC, I hope that moving standard
functions to namespaces will be an opportunity to fix inconsistencies in
parameter order, like:array_map($callback, array)
array_filter($array, $callback)and not just an alias under a namespace!
Maybe off-topic, but I don't think you could "fix" them:
for array_map, the array is variadic-like, so must be last;
for array_filter, the callback is optional, so must be after the array.
(Correct me if I'm wrong.)
--
Guilliam Xavier
Maybe off-topic, but I don't think you could "fix" them:
for array_map, the array is variadic-like, so must be last;
for array_filter, the callback is optional, so must be after the array.
(Correct me if I'm wrong.)--
Guilliam Xavier
Good point. Then that would be an opportunity to question whether
array_map() is doing too much, and should just work on a single array.
Like Array.map()
https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Array/map
in JS, Stream.map()
https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#map-java.util.function.Function-
in Java, Iterator.map()
https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.map in
Rust, etc.
— Benjamin
Le 25/02/2021 à 21:26, Nikita Popov a écrit :
Hi internals,
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.Regards,
Nikita
Hello,
Thank you so much for this RFC, this is a big +1 for me.
There's only one caveat: wouldn't this create name conflicts with some
existing third-party libraries ? Anyway, if it does, it'll conflict with
Array, or Password, or OpenSSL named libraries, and in this case, it
means they have voluntarily ignored the vendoring convention, which is
evil-designed since they would take a common name as root namespaces and
prevent legitimate use of those, and they should probably be fixed.
--
Pierre