> On 23 Aug 2024, at 20:20, Rowan Tommins [IMSoP] <[email protected]> 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?