Re: [RFC][DISCUSSION] PHP Namespace in core

From: Date: Wed, 15 Apr 2020 17:24:05 +0000
Subject: Re: [RFC][DISCUSSION] PHP Namespace in core
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-109663@lists.php.net to get a copy of this message
Hi, Michał Brzuchalski wrote:
Hi Marcio, śr., 15 kwi 2020 o 18:39 Marcio Almada <marcio.web2@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

« previous php.internals (#109663) next »