Re: [Concept] Flip relative function lookup order (global, then local)

> On 23 Aug 2024, at 20:20, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > > On Fri, 23 Aug 2024, at 13:43, Stephen Reay wrote: >> This change would also break existing code that does "the right thing", >> and has the potential to arbitrarily break perfectly valid userland >> code *any time a new global function is added*, forever. > > You replied to me, but you seem to be commenting on one of the other proposals. My preference > is for "unqualified = global", which is a one-off breaking change, which only affects > user-defined functions, which are declared in a namespace, and used in that same namespace. > > You're right that it would mean classes and functions resolve differently, and that's > why I said that if I had a time machine, I would support a different option. But, personally, I > don't think the small long-term inconsistency outweighs the huge short-term disruption of > defaulting to local. > > Regards, > -- > Rowan Tommins > [IMSoP] > Ok well I apologise, I thought you were proposing whatever "current namespace" syntax solution as optional, rather required. I stand by the rest of my argument though. This entire ridiculous discussion about a huge BC break that introduces bizarre inconsistencies, is 100% because a handful of people don't want to type \. Are we going to go through this whole ridiculous dance for classes and interfaces and traits next too? They always need to be prepended with \ (or imported), so I can't begin to imagine what horrors that must be presenting for those poor souls who are allergic to a leading backslash. Perhaps next we can go back to having register_globals and forcing it to always on, because people don't want to type $_GET or $_POST. Perhaps after that we can bring back magic quotes because parameterised queries are too much to type?