Re: [RFC] New core autoloading mechanism with support for function autoloading

On Wed, 12 Apr 2023 at 09:24, Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote: > > To me, class autoloading is a performance feature. If we didn't care about > performance, we would be fine with eagerly loading a bunch of classes as > e.g. Java does. I think (class) autoloading actually serves two purposes: as you say, it allows lazy-loading, which was an important performance consideration before opcache; but it also allows mapping of class name to file name. Java still has to find the source file for each class mentioned, it just has a more rigid set of rules for where it will look. One of the big differences you'll see between PHP 4 and PHP 5 codebases is the number of source files - when people had to manually list each file to include, they tended to bundle things into larger categories; with autoloading, they used one file per class. There's probably more willingness to create new classes in such an arrangement, since they're easier to find. I think function autoloading would provide a similar shift in thinking: rather than one big "functions.php", projects will put smaller batches of functions together in tighter namespaces. That in turn will make it feel more natural to create a new file of functions, rather than using a class full of static methods just to create that grouping. It doesn't enable anything that a script generating a list of include statements couldn't, but PHP users aren't used to needing a "build" command just to discover a new file, so function autoloading feels more natural. Regards, -- Rowan Tommins [IMSoP]