Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109663 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 31490 invoked from network); 15 Apr 2020 18:54:07 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 15 Apr 2020 18:54:07 -0000 To: internals@lists.php.net References: Date: Wed, 15 Apr 2020 19:24:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 46.59.72.204 Subject: Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core From: ajf@ajf.me (Andrea Faulds) Message-ID: Hi, Michał Brzuchalski wrote: > Hi Marcio, > > śr., 15 kwi 2020 o 18:39 Marcio Almada 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