# spl_autoload vs __autoload - Thread: https://externals.io/message/34267 - Original archive: https://news-web.php.net/php.internals/34267 - Started by Andrew Mason on 2007-12-28T11:56:05+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #34267 — Andrew Mason — 2007-12-28T11:56:05+00:00 URL: https://externals.io/message/34267#34267 Hi guys, Can anyone shed some light on the advantages of the spl_autoload over the standard __autoload ? is there any ? kind regards Andrew --- ## #34269 — Alexey Zakhlestin — 2007-12-28T13:13:47+00:00 URL: https://externals.io/message/34267#34269 · In reply to: #34267 > Can anyone shed some light on the advantages of the spl_autoload over > the standard __autoload ? is there any ? sure. spl_autoload allows you to have many independent autoloaders -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #34270 — Stefan Priebsch — 2007-12-28T13:13:47+00:00 URL: https://externals.io/message/34267#34270 · In reply to: #34267 Andrew Mason schrieb: > Hi guys, > Can anyone shed some light on the advantages of the spl_autoload over > the standard __autoload ? is there any ? You can only register one __autoload() function, whereas `spl_autoload()` allows for a hierarchy of handlers. This allows for libraries to register their own autoload handler, for example. Regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F --- ## #34271 — david.coallier@nyphp.com — 2007-12-28T14:30:17+00:00 URL: https://externals.io/message/34267#34271 · In reply to: #34267 > Hi guys, > Can anyone shed some light on the advantages of the spl_autoload over > the standard __autoload ? is there any ? > Please use php-general for that kind of question. > > kind regards > Andrew > > -- > > > > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #34273 — Pierre — 2007-12-28T16:57:00+00:00 URL: https://externals.io/message/34267#34273 · In reply to: #34271 > > > […] > > Please use php-general for that kind of question. This question makes sense here and brings yet again the question why such things are not available by default. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34274 — Andrew Mason — 2007-12-29T01:28:53+00:00 URL: https://externals.io/message/34267#34274 · In reply to: #34273 Thanks for your replies guys. Part of the reason why I asked here is because of a previous posting a while back where Stas seemed to suggest that the spl_autoloader was superior but from reading the api i didn't know if this was purely from a flexibility point of view or if there was more too it. I probably should have been more specific in my question. kind regards Andrew > > > […] > > This question makes sense here and brings yet again the question why > such things are not available by default. > > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org --- ## #34303 — Marcus Boerger — 2007-12-30T17:58:30+00:00 URL: https://externals.io/message/34267#34303 · In reply to: #34274 Hello Andrew, SPL simply allows two things: a) a stack that hooks into __autoload b) a default implementation that may be used (with ot without the former) We try to group functionality into extensions where we seem fit. And by the time I implemented spl_autoload stuff it made sense to put it into the SPL extension. Just because that extension was meant to be the home for more advanced OOP stuff. marcus Saturday, December 29, 2007, 2:28:53 AM, you wrote: > Thanks for your replies guys. > Part of the reason why I asked here is because of a previous posting a > while back where Stas seemed to suggest that the spl_autoloader was > superior but from reading the api i didn't know if this was purely > from a flexibility point of view or if there was more too it. I > probably should have been more specific in my question. > kind regards > Andrew > > > […] Best regards, Marcus --- ## #34306 — Pierre — 2007-12-31T18:31:40+00:00 URL: https://externals.io/message/34267#34306 · In reply to: #34303 > Hello Andrew, > > SPL simply allows two things: > a) a stack that hooks into __autoload > b) a default implementation that may be used (with ot without the former) > > We try to group functionality into extensions where we seem fit. And by the > time I implemented spl_autoload stuff it made sense to put it into the SPL > extension. Just because that extension was meant to be the home for more > advanced OOP stuff. I see nothing advanced in these features and a couple of other neither (we gave a short list already). Can we at least always enabled by in 5.3 and be done with it? It is annoying to have setups without it. Happy new year! :-) -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34307 — Marcus Boerger — 2007-12-31T21:45:47+00:00 URL: https://externals.io/message/34267#34307 · In reply to: #34306 Hello Johannes, I agree with Pierre here. How about finally making SPL built in always like ext/standard? marcus Monday, December 31, 2007, 7:31:40 PM, you wrote: > > > […] > I see nothing advanced in these features and a couple of other neither > (we gave a short list already). Can we at least always enabled by in > 5.3 and be done with it? It is annoying to have setups without it. > Happy new year! :-) Best regards, Marcus --- ## #34310 — Greg Beaver — 2007-12-31T23:06:11+00:00 URL: https://externals.io/message/34267#34310 · In reply to: #34307 Marcus Boerger wrote: > Hello Johannes, > > I agree with Pierre here. How about finally making SPL built in always > like ext/standard? +1 --- ## #34311 — David Coallier — 2007-12-31T23:25:41+00:00 URL: https://externals.io/message/34267#34311 · In reply to: #34310 > Marcus Boerger wrote: > > […] > > +1 > > Finally... +1 > -- > > > > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #34314 — johannes@php.net — 2008-01-01T17:02:50+00:00 URL: https://externals.io/message/34267#34314 · In reply to: #34307 Hi, > Hello Johannes, > > I agree with Pierre here. How about finally making SPL built in > always > like ext/standard? First some statistics: According to my numbers[1], which are as wrong as most other statistics about such stuff. 1% (36 of 3573) of the PHP 5 installations have SPL disabled. So imo having it not forced-on is not a big problem for users. The only ones who might complain about enforcing it are people trying to run PHP on embedded platforms, but they already have to do some changes here and there so I don't see that as a problem either. On the other side, from the internals point of view, I see benefits for us like that we can rely on SPL Exceptions really being there without #ifdef'ing around (see ext/mysqlit -> RuntimeException vs. Exception) and such stuff. So in the end I'm +1 on the proposal for 5.3. On a related note: Imo for users the real problems are different extensions, which we won't enable by default (due to their dependency on external stuff) and which might be available on some host or different php.ini settings. For instance I was once annoyed by zlib not being available on a shared host or png not available for gd. While I know that it is hard for us to reach these people (and most of us here aren't interested in shared hosts anyways) that's what I'd like to think about. Many people try to write apps which run "everywhere" - That's one of the reasons for PHP's success - but this also means they can only rely on a limited set of functionality... johannes [1] Counting installations of a random PHP app (phpMyFAQ) where the user agreed to send the data --- ## #34315 — Pierre — 2008-01-01T17:35:28+00:00 URL: https://externals.io/message/34267#34315 · In reply to: #34314 > Hi, > > > > […] > > First some statistics: According to my numbers[1], which are as wrong as > most other statistics about such stuff. 1% (36 of 3573) of the PHP 5 > installations have SPL disabled. So imo having it not forced-on is not a > big problem for users. The point is to do not have to worry about it being disabled. Besides that statistics are pretty useless in this case (consider a large intranet full of spless setups where you have to work and you are done...). > So in the end I'm +1 on the proposal for 5.3. so let enable it :) > > On a related note: Imo for users the real problems are different > extensions, which we won't enable by default (due to their dependency on > external stuff) and which might be available on some host or different > php.ini settings. For instance I was once annoyed by zlib not being > available on a shared host or png not available for gd. ISP not providing PNG? go to another :) But I thought we can't build ext/gd without png, I have to check that again. Happy new year :) -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34317 — mgagne@generationphp.net — 2008-01-01T19:24:39+00:00 URL: https://externals.io/message/34267#34317 · In reply to: #34315 Pierre wrote: > > […] > > ISP not providing PNG? go to another :) But I thought we can't build > ext/gd without png, I have to check that again. cPanel does not enable GD by default. -- Mathieu