I am well familiar with this approach, and it does not scale - not only would you be aggressively loading every installed view-helper anytime you render a view, you would even be loading them when you're *not* rendering a view.
I'm afraid the best we could do at this point, without changing the language, is a establish a convention for autoloading functions (and/or namespaces of functions) from files, based on static analysis of template files. But that is pretty complex - on the organizational side, it requires developers to agree on and adopt a convention, and on the technical side, you need static analysis and thereby most likely a cache layer as well. It's all possible, but most people aren't going to put up with this much complexity for something this simple. Hmm. What if we could import static methods into file scope and use them as functions? use My\Namespace::my_function; my_function(); // <-- effectively My\Namespace::my_function() This would leverage auto-loading at least... I mean, it's still effectively just abusing classes as pseudo-namespaces, so there is that - but it would work with e.g. Composer right away, and probably with many existing static classes? Yeah, it's still ugly... On Sun, Jun 19, 2016 at 11:37 AM, Marco Pivetta <ocram...@gmail.com> wrote: > On 19 June 2016 at 11:34, Rasmus Schultz <ras...@mindplay.dk> wrote: >> >> > You can always add more functions to a namespace even spread accross >> > multiple files >> >> Same problem: no autoloading. >> >> You would have to add require_one statements - which, as said, is not >> really possible with Composer packages... >> > > You should look at packages that already do this: > https://github.com/nikic/iter/blob/5527ca489bf151ceef17622f1c89114640f522d2/composer.json#L16 > > Ref: https://getcomposer.org/doc/04-schema.md#files > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
