Re: [RFC] PHP Namespace Policy

> On Apr 27, 2020, at 6:05 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > So you'd be happy with PHP\str_contains and \str_replace next to each other indefinitely? Absolutely. The benefits of having a PHP namespace would outweigh the lack of elegance above. OTOH I'm not sure why we could not have *both* \str_replace and PHP\str_replace, with a plan to deprecate the former many versions from now. > Or, more in line with your proposal, a hypothetical PHP\Iterators\FractallyAwesomeIterator next > to \InifiniteIterator, \LimitIterator, etc? Or did you have some stronger definition of "newer > things" in mind? Newer things === things that come chronologically after an RFC is approved. If we have to ensure elegance across the entire language it becomes very hard to ever improve it as new things are usually inconsistent with less-elegant prior approaches. > I don't really see what such an arbitrary split would gain us, other than a lot of > confusion. The "arbitrary split" is not what where we would see the gain, that is just an unfortunately inconvenience. The gain would come from having a PHP namespace where we don't have to worry about naming conflicts in user-land moving forward. The former is an acceptable tradeoff to gain the latter. IMO anyway. But YMMV. > Importantly, it wouldn't be following the lead of the other languages and frameworks you > mentioned, which was the specific point I was responding to. Did I mention other languages and frameworks? I just wrote the simple reply above saying "newer things go in, older ones stay out." -Mike