Re: RFC Proposal - static modifier for classes

> On 23 Nov 2023, at 19:42, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On Thu, 23 Nov 2023 at 11:48, Stephen Reay <stephen@koalephant.com> wrote: > >> >> Respectively, I disagree that it's "not a big problem" if your goal is to >> encourage people to use regular functions over classes with static methods. >> > > > Just to be clear, my answer was specifically addressing your point about > using Composer as an argument for not including things. > > I was not saying "... and therefore the argument is true", only "... and > therefore we can discuss the argument without mentioning Composer if we > want to". > > Fair enough, apologies for misunderstanding what you were saying there. > >> PHP ships with a built in class autoloader function, and pretending that > using 'require_once' everywhere a function is used, is just as easy for the > developer seem disingenuous to be honest. > > PHP ships with *the ability to configure* an autoloading function; it will > not load any files without you first telling it where to look. I'm talking about php's builtin *implementation* of an autoloader not just support for the *concept* of class autoloading using a userland function. Out of the box, with no package manager or module loader or anything, you can do as little as call spl_autoload_register with no arguments, and have working class autoloading. Yes you *may* also end up setting the include path and/or autoload extensions at runtime, or even writing a custom autoload implementation - but none of that is required for it to work. > The > workaround being proposed is not to use require_once every time you want a > function, it's to use require_once in the same place you configure your > autoloader. > > I totally agree that we can debate whether that workaround is sufficient. > I'm just trying to frame that debate as "autoloading vs require", rather > than a distraction of "Composer vs something else". > Ok, again, apologies for the misunderstanding of the point you're making - and thank you, I agree that is a better way to frame the debate, when it comes to language / stdlib features. > > Regards, > -- > Rowan Tommins > [IMSoP]