Hi guys,
Can anyone shed some light on the advantages of the spl_autoload over
the standard __autoload ? is there any ?
kind regards
Andrew
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
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/
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
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.
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
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
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.
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
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
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.
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
Best regards,
Marcus
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! :-)
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:
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! :-)
Best regards,
Marcus
Marcus Boerger wrote:
Hello Johannes,
I agree with Pierre here. How about finally making SPL built in always
like ext/standard?
+1
Marcus Boerger wrote:
Hello Johannes,
I agree with Pierre here. How about finally making SPL built in always
like ext/standard?+1
Finally...
+1
--
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
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
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 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
Pierre wrote:
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.
cPanel does not enable GD by default.
--
Mathieu