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?" 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. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
