Re: Re: [RFC] PHP Namespace Policy

On Mon, Apr 27, 2020 at 11:26 AM Rowan Tommins <rowan.collins@gmail.com> wrote: > To me, the answer to that is quite simple: we have several hundred > functions, and several dozen classes and interfaces, which are not in such > a namespace; and we have millions of lines of code out in the world using > them. So either we need a strong rationale and a concrete plan to move all > of those into the namespace, or we need a consistent policy on what goes in > and what stays out. To me as an end-user, the ability to write readable code is as important as ability to write code that performs well and is well-tested. All these prefixes, like PhpAttribute being discussed right now, only decrease readability. I'd rather have to import \PHP\Attribute or use plain ol' \Attribute but no prefixes pretty please. I know they can be renamed locally via use PhpFoo as Foo; but that's a kludge. > It wouldn't make much sense, for instance, to have > PHP\str_contains but no plan to move str_replace. We don't have to mix namespaced and non-namespaced stuff within the same area, thus all str* functions should remain unnamespaced, and honestly I personally don't care if _functions_ are in \ or \PHP. I, however, would love if no new classes in PHP were prefixed. -- Best regards, Max Semenik