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