On Sat, Apr 25, 2020 at 3:28 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> Hi Michael, > > On 25 April 2020 00:00:32 BST, Michael Morris <tendo...@gmail.com> wrote: > >Changing function names and argument orders would lead to BC breaks so > >massive people would move away without a transition plan that was > >sustainable long term. Namespaces give that opportunity, I think. > > > You're not the first person to suggest this, indeed I've thought of trying > to write an FAQ for the list, and this would be on it. > > There is some merit to the idea, but there's a snag: just using new names > for new versions of things (which is what a new namespace would be) helps > *machines* know which is which, but it doesn't help *humans* know which is > which. Instead of "Does strpos take needle or haystack first?" the user > would now have to think "Is this file using the old or new functions? Is > one of them called str_pos and the other strpos, and do they take arguments > in a different order?" > I'm aware of this pain point, but I have to deal with it when moving between languages anyway. A project that uses both older and newer versions of the same function is going to happen regardless of the namespace it is placed in, and if namespaces aren't used then the names just keep getting longer and longer. > > The general consensus is that the long-term solution is to add new > object-oriented APIs, including "scalar objects" (syntax to call methods in > strings, integers, etc). That's not necessarily because OO is better, but > because it's sufficiently different that it can comfortably sit side by > side with the current functions. We might have > $haystack->positionOf($needle) or $needle->positionIn($haystack) or both, > and strpos would still be available to all programs with the same arguments > it's had for 20 years. > Similarly, an OO-based file handling API would give us a chance to design > in better error handling so there was no need for the @ operator and lots > of ===false checks. That new API is the kind of thing that could live under > the \PHP namespace, but the old functions wouldn't need to move anywhere. > > I like these ideas, but they don't address the point I was making I would like the old "throw it all in" approach to be moved out of \ and into \PHP\Legacy. Why? I want \ to be empty. Long term I feel this is the best approach because it matches nearly all other languages. Wouldn't that break everything? Yes, which is the reason for a mechanism to allow the user to configure which namespaces are loaded onto the root. By default, this will be /PHP/Legacy so that Legacy code will be able to run unimpeded. Or is \ itself just going to be legacy? I suppose that could be done, but functions without a namespace at all irks me. > >
