> On 23 Aug 2024, at 15:29, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
>
> having global as the default mode (even if we provide an option for local) is
> much less disruptive to existing code.
Hi Rowan,
I don't disagree with this summary of the current state, but I think this
misses an important factor: namespaced functions are currently nowhere near as
popular as namespaced classes, and a significant part of that is almost
certainly because we don't have function autoloading, nor any kind of
visibility controls for functions (eg package private).
Making relative function names do the opposite of relative class names sounds
like a great way to permanently kill any prospects of encouraging developers to
use regular namespaced functions in place of static classes as "bag of
functions", which is what we keep hearing we should use - most notably on a
recent RFC to embody the concept of a static class.
So we're told "no don't use classes for static functions like that, use proper
functions".
We already can't autoload them which makes them less appealing, and less
practical.
In a world where global functions take precedence over local ones because some
people don't like writing a single \ character, autoloading would be a moot
point because if you preference global functions you're implicitly telling
developers they shouldn't write namespaced functions, by making them harder and
less intuitive to use.
Cheers
Stephen
