Hi,
Michał Brzuchalski wrote:
Hi Marcio,
śr., 15 kwi 2020 o 18:39 Marcio Almada <marcio.w...@gmail.com> napisał(a):
Even though I'm fond to the idea of languages having the official
stdlib contained
into a single space, there seems to be no practicality on a \PHP namespace
usage
at this point IMMO.
We would be in a situation where things are either mixed in and out
the new namespace
- Should I `use function PHP\{json_encode, json_decode}` or was it in
the root??? - or
everything that already exists must first receive an alias into this
new namespace, to allow
consistency... but then there would probably be no plans ever to
actually move existing stuff
into the new prefix in the future.
You've misunderstood the idea. Standard library functions classes etc. are
not language features.
It's not a purpose of this RFC to move existing functions from the standard
library but to allow core language features
to use it. Described examples show benefit in use for symbols tightly
coupled to features PHP as a language delivers.
Most of the standard library function can be replaced by implementations in
PHP or by wrapping around a C library.
The features tightly coupled with the language is for eg. the Reflection
mechanism, PhpToken class as described.
Upcoming PhpAttributes for which proposal is a work in progress.
Those all features will not likely be moved to PECL and this RFC proposal
is to allow features like that to use PHP namespace.
We already have PHP language features relying on classes in the root
namespace (Closure, Throwable, ArrayAccess, etc) so the point Marcio
makes about inconsistency is nonetheless valid I think.
Thanks,
Andrea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
