RE: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
| From: | John Crenshaw | Date: | Thu, 18 Aug 2011 01:49:43 +0000 |
| Subject: | RE: [PHP-DEV] [RFC] Function autoloading through spl_autoload* | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-54669@lists.php.net to get a copy of this message | ||
> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Wednesday, August 17, 2011 7:37 PM
> To: Matthew Weier O'Phinney
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
>
> Hi!
>
> On 8/17/11 2:44 PM, Matthew Weier O'Phinney wrote:
> > There's nothing saying you can't have the exact same situation right now
> > with classes and autoloading, too.
>
> Well, there is something - the "file per class" custom which is followed
> quite widely.
>
> And also classes don't have fallbacks, while the functions do.
>
> > While I understand your objections, I think that after the functionality
> > exists, there can be discussions about best practices -- e.g., putting
> > one function per file when autoloading, or documenting when all
>
> I'm not sure anybody would really do function-per-file - it's too tedious..
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
Tedious, and slow because the overhead for each file loaded can easily be in the 2-5ms range. Nobody
is going to have a function per file, but they are still likely to use function autoloading in other
ways. A likely case for this would be to autoload a group of functions that all share the same
prefix. Another case might be to autoload a set of functions that are related to something else (for
example, usability of singleton classes would benefit greatly from having a function of the same
name as the class, or classes may want to provide a factory function of the same name.)
John Crenshaw
Priacta, Inc.
P.S. Before someone flames me about the evilness of singletons, yes, I know; but, occasionally they
still have a place. There is usually only one session, there is only one app, there is usually only
one database, logging is usually configured globally, etc.