On Sat, Jun 10, 2017 at 12:11 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 6/3/2017 6:40 PM, Fleshgrinder wrote: >> Next promised RFC (and the last one for this weekend): >> >> https://wiki.php.net/rfc/namespaces-in-core >> >> I am unsure about whether we should avoid the usage of abbreviations for >> things like language (lang), standard (std), and utility (util). I think >> it is not necessary to write them out fully, but, well, ...?!? >> > > Bump, would love some feedback on the RFC and the open issues. Otherwise > this goes into voting and lots of complains pop up. It would be much > more efficient to use the discussion time for that. > > -- > Richard "Fleshgrinder" Fussenegger >
I gave this feedback before but I'll repeat it. I support namespaces in the core, with the `PHP` namespace (with whatever capitalization we decide) to be reserved *solely* for things related to the language itself such as lexer, parser, etc. I am fine with other extensions using namespaces but should use appropriately named ones. Using the `PHP` namespace to indicate something is packaged in core is a poor decision. We have moved existing extensions into core and it would not make sense to rename it simply because it was moved into core because it's a backwards compatibility break. Similarly we've moved at least one extension out of core and it doesn't make sense for it to have the `PHP` name when it's not in core, but renaming it is yet other backwards compatibility break. It's simply not prudent. Instead extensions should be named after what they are, the vendor they are for, or some other name; this is the same process user-land packages go through and core should not be different. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
