Sort of related to the "Requirements for things you will release" thread, this weekend I've been trying to work out whether or not to use __autoload() in a new project. I really like autoloading, it's useful and it can save on resources by not loading unnecessary classes. Ace. On the face of it I'd use it in a shot.
But..
The application I'm writing is aimed at being "embeddable" into other websites. The problem with that is that if I've autoloaded things then, if the website also uses an autoloader the chances are they won't play very nicely together. There is a possible solution I could implement that would use __autoload() if the app was running in "standalone" mode or include all the classes using a require_once() include file if it's embedded, but I don't really like that idea.
Have you ever faced this dilemma? What would you do?
__autoload() .. to use or not to use.
Moderator: General Moderators
Re: __autoload() .. to use or not to use.
Hmm, how savvy will the intended audience be? Me thinks if they do use autoload and they can provide the scenario it is used in, is_callable() might be useful.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: __autoload() .. to use or not to use.
spl_autoload_register().
You end up with min requirements being PHP 5.1.2 for that though.
You end up with min requirements being PHP 5.1.2 for that though.
Re: __autoload() .. to use or not to use.
ooo.. that looks useful. Cheers.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Re: __autoload() .. to use or not to use.
Using autoload in HTML Purifier was one of the primary migration concerns when I released 3.1.0. To get an idea of how much documentation I had to write, check this page out. And I'm not even sure if that's enough.
But I do think autoload is good. It gives you lots of flexibility with the source files; with a little code generation I can run HTML Purifier without autoload on at all.
But I do think autoload is good. It gives you lots of flexibility with the source files; with a little code generation I can run HTML Purifier without autoload on at all.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Re: __autoload() .. to use or not to use.
Look on the bright side. Autoloading lost most of it's glaring problems and issues after PHP 5.2 - it's now adopted (in some incarnation) by PEAR and the Zend Framework. The ZF is kind of questionable - they still use require_once() everywhere which defeats part of one advantage (lazy loading).
I think the main challenge is making the introduction of autoloading via SPL as simplistic as possible, and ensuring it's optional! I still tend to implement an application specific __autoload simply because most PHP5 libraries utilise the ultra predictable PEAR naming convention. Why have 5 autoloading functions, when 1 generic one works for everything?
I think the main challenge is making the introduction of autoloading via SPL as simplistic as possible, and ensuring it's optional! I still tend to implement an application specific __autoload simply because most PHP5 libraries utilise the ultra predictable PEAR naming convention. Why have 5 autoloading functions, when 1 generic one works for everything?
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Re: __autoload() .. to use or not to use.
+1 spl_autoload_register().
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Re: __autoload() .. to use or not to use.
I just thought of this...
Another consideration when you're using spl_autoload_register is the order and specificity of the autoloaders. It's not unusual for the base application to specify a catch-all autoloader. However, if a library autoloader is registered later (it probably will be), it will never be seen: the catch all will always process it. This may or may not cause errors.
Another consideration when you're using spl_autoload_register is the order and specificity of the autoloaders. It's not unusual for the base application to specify a catch-all autoloader. However, if a library autoloader is registered later (it probably will be), it will never be seen: the catch all will always process it. This may or may not cause errors.