Re: RFC Proposal - static modifier for classes

> On 23 Nov 2023, at 17:21, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On Thu, 23 Nov 2023 at 06:00, Stephen Reay <php-lists@koalephant.com> wrote: > >> I'm disappointed to see yet again that there's this implied notion that >> working with PHP in 2023 means "well surely you must be using composer", >> which leads to "but composer..." somehow being an accepted argument when >> it comes to missing/incomplete builtin functionality. >> > > > While I appreciate your point in the general case, in this particular > thread, the mentions of Composer are really just examples, or can be > reworded that way: > > Functions lack autoloading, but in practice this isn't a big problem > because you can just require_once a file defining them, and as long as > OpCache is running there's very little performance penalty. If you're using > a package manager or module loading system to integrate multiple > autoloaders, it's generally easy to add one or more required files as part > of the package / module config - *for example* Composer has a "files" array > in each package's "autoload" config. > > So the actual assumption is "surely you must be using OpCache", which > unlike Composer is bundled with PHP. > > Regards, > -- > Rowan Tommins > [IMSoP] (Resending from list-address) Hi Rowan, 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. "No autoloading" is clearly a well known barrier to the use of userland functions, and "rewriting 'use composer' to 'use require_once'" isn't a comparable workaround, as evidenced by: - https://wiki.php.net/rfc/core-autoloading (from April 2023) paragraph 2 says: > The need for such a feature seems very clear as users will create “helper” classes with > static methods to take advantage of autoloading via the class autoloading mechanism. An email earlier in this thread makes the same point (shiny gold sticker if you remember who wrote this): > The only issue being that we don't have good autoloading support for such functions, and > that's a whole different problem... > you can just require_once a file defining them, To paraphrase a certain secret agent: Do you want people writing faux-namespace classes? Because this is how you get people writing faux-namespace classes. > So the actual assumption is No, the assumption was very clearly written: > Autoloading is frankly mostly solved by using the files block > in your composer.json's autoload config, and then you don't need to care. Saying "a package loader" instead of "composer" isn't any better really. Autoloading of classes in PHP doesn't require a "package loader" to work. 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. Cheers Stephen