All,
One problem that became apparent after the introduction of __autoload(), is
that different pieces of code, sometimes coming from different sources, may
want to declare this function in a different way. Today, __autoload() is
treated like any other function, so it's impossible to re-declare it.
Marcus tried to solve it by introducing an __autoload() wrapper in
SPL. Personally I think it's probably not the right way to go, but that's
beside the point right now.
What I'd like to suggest is a change in the behavior of __autoload(), so
that multiple __autoload()'s could be defined. Essentially, declaring
__autoload() would in fact add the function to the list of functions that
are called in case a missing class is referenced. However, it will not
actually place a function named __autoload() in the PHP function
table. That way, it would be possible to declare multiple __autoloads(),
and have all of them called when a missing class is spotted.
The two issues with this solution are:
- It will be impossible to use the standard means to determine whether
__autoload() is declared or not. I don't think that's a very important
issue but it's there nonetheless. - We need to determine what makes sense as far as calling order if we
have more than one __autoload(). My guess would be calling them in the
order they were registered, and checking whether the class was defined
after each one (if it was - stop).
That solution maintains downwards compatibility (almost, other than issue #1).
Thoughts?
Zeev
At 14:21 03/04/2005, Andrey Hristov wrote:
Zeev Suraski wrote:
All,
One problem that became apparent after the introduction of __autoload(),
is that different pieces of code, sometimes coming from different
sources, may want to declare this function in a different way. Today,
__autoload() is treated like any other function, so it's impossible to
re-declare it.
Marcus tried to solve it by introducing an __autoload() wrapper in SPL.
Personally I think it's probably not the right way to go, but that's
beside the point right now.
What I'd like to suggest is a change in the behavior of __autoload(), so
that multiple __autoload()'s could be defined. Essentially, declaring
__autoload() would in fact add the function to the list of functions that
are called in case a missing class is referenced. However, it will not
actually place a function named __autoload() in the PHP function
table. That way, it would be possible to declare multiple __autoloads(),
and have all of them called when a missing class is spotted.
The two issues with this solution are:
- It will be impossible to use the standard means to determine whether
__autoload() is declared or not. I don't think that's a very important
issue but it's there nonetheless.- We need to determine what makes sense as far as calling order if we
have more than one __autoload(). My guess would be calling them in the
order they were registered, and checking whether the class was defined
after each one (if it was - stop).
That solution maintains downwards compatibility (almost, other than issue
#1).
Thoughts?
Zeev
Hi Zeev,
if there will be chained __autoload() functions, isn´t it a good idea
to give to the user the possibility to register autoload funcs like it is
with the shutdown functions. I think that the user creating the queue is more
reliable than relying on the include file order except if all the __autoload()
appear in one file in the sequence they are going to be used. Therefore every
submodule of a system can register it´s own __autoload() which will know how
to handle the module classes. The handling can be different for another
module.
Why should the order of the queue matter? Regardless of which solution we
pick, it will be pretty hellish if the system behaves differently based on
the order of autoload()'s. The benefit of using __autoload() is that it's
downwards compatible.
Zeev
At 15:18 03/04/2005, Andrey Hristov wrote:
Hi Zeev,
the idea one __autoload() may not be capable of loading therefore the next
one in the chain should be executed to try to load/define the needed code.
bool(false) returned from __autoload() means try with the next in the chain,
bool(true) everything went fine skip the rest of the queue.
What I had in mind (primarily to maintain downwards compatibility), is that
the engine will check whether the class exists after each call to an
autload() callback. If it exists - control returns to the script. If it
doesn't - the next autoload() is called. That way we don't need to rely on
return values.
Either way, though, the order shouldn't matter...
Zeev
Zeev Suraski wrote:
All,
One problem that became apparent after the introduction of __autoload(),
is that different pieces of code, sometimes coming from different
sources, may want to declare this function in a different way. Today,
__autoload() is treated like any other function, so it's impossible to
re-declare it.Marcus tried to solve it by introducing an __autoload() wrapper in SPL.
Personally I think it's probably not the right way to go, but that's
beside the point right now.What I'd like to suggest is a change in the behavior of __autoload(), so
that multiple __autoload()'s could be defined. Essentially, declaring
__autoload() would in fact add the function to the list of functions
that are called in case a missing class is referenced. However, it will
not actually place a function named __autoload() in the PHP function
table. That way, it would be possible to declare multiple
__autoloads(), and have all of them called when a missing class is spotted.The two issues with this solution are:
- It will be impossible to use the standard means to determine whether
__autoload() is declared or not. I don't think that's a very important
issue but it's there nonetheless.- We need to determine what makes sense as far as calling order if we
have more than one __autoload(). My guess would be calling them in the
order they were registered, and checking whether the class was defined
after each one (if it was - stop).That solution maintains downwards compatibility (almost, other than
issue #1).Thoughts?
Zeev
Hi Zeev,
the idea one __autoload() may not be capable of loading therefore the next
one in the chain should be executed to try to load/define the needed code.
bool(false) returned from __autoload() means try with the next in the chain,
bool(true) everything went fine skip the rest of the queue.
Andrey
I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html
and slightly related
http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
+optimization+too+many%3F.html
It's pretty clear that people want to use autoload to save them having
to deal with include paths.. (and perhaps save a few stat calls) - the
more straightforward solution would be to add a include/require callback
handler - so that rather than a class instantation action, magically
doing file operations, you had a simpler and more obvious way to manage
inclusions.
But I guess Until I bother hacking something up for it, it'll remain
little more than another heckle from the audience. ;)
Regards
Alan
All,
One problem that became apparent after the introduction of __autoload(), is
that different pieces of code, sometimes coming from different sources, may
want to declare this function in a different way. Today, __autoload() is
treated like any other function, so it's impossible to re-declare it.Marcus tried to solve it by introducing an __autoload() wrapper in
SPL. Personally I think it's probably not the right way to go, but that's
beside the point right now.What I'd like to suggest is a change in the behavior of __autoload(), so
that multiple __autoload()'s could be defined. Essentially, declaring
__autoload() would in fact add the function to the list of functions that
are called in case a missing class is referenced. However, it will not
actually place a function named __autoload() in the PHP function
table. That way, it would be possible to declare multiple __autoloads(),
and have all of them called when a missing class is spotted.The two issues with this solution are:
- It will be impossible to use the standard means to determine whether
__autoload() is declared or not. I don't think that's a very important
issue but it's there nonetheless.- We need to determine what makes sense as far as calling order if we
have more than one __autoload(). My guess would be calling them in the
order they were registered, and checking whether the class was defined
after each one (if it was - stop).That solution maintains downwards compatibility (almost, other than issue #1).
Thoughts?
Zeev
Alan Knowles wrote:
I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.htmland slightly related
http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
+optimization+too+many%3F.htmlIt's pretty clear that people want to use autoload to save them having
to deal with include paths.. (and perhaps save a few stat calls) - the
more straightforward solution would be to add a include/require callback
handler - so that rather than a class instantation action, magically
doing file operations, you had a simpler and more obvious way to manage
inclusions.But I guess Until I bother hacking something up for it, it'll remain
little more than another heckle from the audience. ;)
Frameworks should provide __autoload() helper methods, but should never
implement the function itself. Its upto the enduser to do this. This is
the only way it makes sense. Otherwise most of Alan's horror scenarios
actually come true. The cleanest way indeed is to be able to set the
function name for autoloading as a callback. We we have this now via
spl. So I dont see a point messing with it and thereby making this tool
unmaintainable and totaly inconsistent with the reset of the language. I
can already see it .. in 5 years there will be books on php __autoload().
regards,
Lukas
What I'd like to suggest is a change in the behavior of __autoload(),
so that multiple __autoload()'s could be defined. Essentially,
declaring __autoload() would in fact add the function to the list of
functions that are called in case a missing class is referenced.
However, it will not actually place a function named __autoload() in
the PHP function table. That way, it would be possible to declare
multiple __autoloads(), and have all of them called when a missing
class is spotted.
Coupled with namespaces, declaring multiple __autoload functions seems
natural:
namespace x {
function __autoload() {
}
...
}
namespace y {
function __autoload() {
}
...
}
Absent namespaces, the symbol table manipulation seems a bit magical to
me.
Just brainstorming here, but why not an __autoload for functions?
At 18:31 03/04/2005, Marcus Boerger wrote:
Right from the beginning i said __autoload() is just wrong and we need the
described behavior. However all i got back is that i am just wrong and we
don't need it. And that from everybody. But since SPL already gives all
you mentioned there is no reason to do anything more.I'll come back here once i have my Montreal slides online which documnets
everthing or i may also find time to do documentation soon.
Marcus,
Regardless of what happened, I don't see how this piece of functionality
belongs in SPL. SPL isn't a backdoor for introducing whatever you want
into PHP without discussion, is it? :)
Zeev
Hello Zeev,
Sunday, April 3, 2005, 10:39:39 AM, you wrote:
At 18:31 03/04/2005, Marcus Boerger wrote:
Right from the beginning i said __autoload() is just wrong and we need the
described behavior. However all i got back is that i am just wrong and we
don't need it. And that from everybody. But since SPL already gives all
you mentioned there is no reason to do anything more.I'll come back here once i have my Montreal slides online which documnets
everthing or i may also find time to do documentation soon.
Marcus,
Regardless of what happened, I don't see how this piece of functionality
belongs in SPL. SPL isn't a backdoor for introducing whatever you want
into PHP without discussion, is it? :)
No, it's the place where i do my stuff and stuff others want to have also.
And it is the place i am responsible for. And since it is all about making
use of php's new object orientation it is a very good place to put advanced
stuff into.
--
Best regards,
Marcus mailto:mail@marcus-boerger.de
Alan,
Your blog entry is actually what made me look into that topic. I'm not
sure whether I agree with you regarding the general necessity of
__autoload(). __autoload() is not only about saving the headache of
explicit require()'s, it's also about 'JITing' this task, so that no
classes are loaded unless you actually use them.
The main things I took from there are that __autoload() is broken since
it's limited to just one declaration, and that somehow an alternative was
introduced into SPL, which is slightly scary.
Zeev
At 15:58 03/04/2005, Alan Knowles wrote:
I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.htmland slightly related
http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
+optimization+too+many%3F.htmlIt's pretty clear that people want to use autoload to save them having
to deal with include paths.. (and perhaps save a few stat calls) - the
more straightforward solution would be to add a include/require callback
handler - so that rather than a class instantation action, magically
doing file operations, you had a simpler and more obvious way to manage
inclusions.But I guess Until I bother hacking something up for it, it'll remain
little more than another heckle from the audience. ;)Regards
AlanAll,
One problem that became apparent after the introduction of
__autoload(), is
that different pieces of code, sometimes coming from different sources,
may
want to declare this function in a different way. Today, __autoload() is
treated like any other function, so it's impossible to re-declare it.Marcus tried to solve it by introducing an __autoload() wrapper in
SPL. Personally I think it's probably not the right way to go, but that's
beside the point right now.What I'd like to suggest is a change in the behavior of __autoload(), so
that multiple __autoload()'s could be defined. Essentially, declaring
__autoload() would in fact add the function to the list of functions that
are called in case a missing class is referenced. However, it will not
actually place a function named __autoload() in the PHP function
table. That way, it would be possible to declare multiple __autoloads(),
and have all of them called when a missing class is spotted.The two issues with this solution are:
- It will be impossible to use the standard means to determine whether
__autoload() is declared or not. I don't think that's a very important
issue but it's there nonetheless.- We need to determine what makes sense as far as calling order if we
have more than one __autoload(). My guess would be calling them in the
order they were registered, and checking whether the class was defined
after each one (if it was - stop).That solution maintains downwards compatibility (almost, other than
issue #1).Thoughts?
Zeev
Zeev Suraski wrote:
All,
One problem that became apparent after the introduction of __autoload(),
is that different pieces of code, sometimes coming from different
sources, may want to declare this function in a different way. Today,
__autoload() is treated like any other function, so it's impossible to
re-declare it.Marcus tried to solve it by introducing an __autoload() wrapper in SPL.
Personally I think it's probably not the right way to go, but that's
beside the point right now.What I'd like to suggest is a change in the behavior of __autoload(), so
that multiple __autoload()'s could be defined. Essentially, declaring
__autoload() would in fact add the function to the list of functions
that are called in case a missing class is referenced. However, it will
not actually place a function named __autoload() in the PHP function
table. That way, it would be possible to declare multiple
__autoloads(), and have all of them called when a missing class is spotted.The two issues with this solution are:
- It will be impossible to use the standard means to determine whether
__autoload() is declared or not. I don't think that's a very important
issue but it's there nonetheless.- We need to determine what makes sense as far as calling order if we
have more than one __autoload(). My guess would be calling them in the
order they were registered, and checking whether the class was defined
after each one (if it was - stop).That solution maintains downwards compatibility (almost, other than
issue #1).Thoughts?
Don't forget
- If a library has an obscure bug in __autoload, the only error message
the user will see is:
"undefined class XXXX"
If __autoload() is going to gain the ability to be defined for a
library, then the error messages must be enhanced as well.
There is a possible solution:
- document that coders of __autoload() should throw an
autoload_exception if a class is not found
How difficult would it be to have a zend_autoload_throw() that would
bubble up to the next __autoload() and save the exceptions in a hash for
later display if necessary (exceptions need not be the actual
implementation, obviously)? This way, each exception message thrown by
an autoload could be displayed after the "undefined class XXXX",
eliminating a large portion of the magic that makes debugging multiple
__autoload() impossible right now.
Greg
GB>>3. If a library has an obscure bug in __autoload, the only error message
GB>>the user will see is:
GB>>
GB>>"undefined class XXXX"
GB>>
GB>>If __autoload() is going to gain the ability to be defined for a
GB>>library, then the error messages must be enhanced as well.
Shouldn't that bug result in some error message by itself? If it doesn't,
there's probably nothing to add to "undefined class" anyway.
GB>>1) document that coders of __autoload() should throw an
GB>>autoload_exception if a class is not found
Why just not return false or something? Exception is supposed to be used
when things are so bad you just can not continue. But I don't think class
not being found is such situation for autoload.
On the other hand, I think that multiple autoload functions should be
evaluated in isoplated way - so that exception, etc. in one of them would
terminate it, but not the whole autoload process (i.e., next one would be
run).
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Stanislav Malyshev wrote:
GB>>3. If a library has an obscure bug in __autoload, the only error message
GB>>the user will see is:
GB>>
GB>>"undefined class XXXX"
GB>>
GB>>If __autoload() is going to gain the ability to be defined for a
GB>>library, then the error messages must be enhanced as well.Shouldn't that bug result in some error message by itself? If it doesn't,
there's probably nothing to add to "undefined class" anyway.
I meant a logic error - as in the user forgot to use a
DIRECTORY_SEPARATOR and so can't find any of the classes, not an obvious
PHP error.
GB>>1) document that coders of __autoload() should throw an
GB>>autoload_exception if a class is not foundWhy just not return false or something? Exception is supposed to be used
when things are so bad you just can not continue. But I don't think class
not being found is such situation for autoload.On the other hand, I think that multiple autoload functions should be
evaluated in isoplated way - so that exception, etc. in one of them would
terminate it, but not the whole autoload process (i.e., next one would be
run).
Perhaps a better solution is to simply augment the "undefined class XXX"
method with a brief listing of all the defined __autoload() functions,
so the user knows where to look for magic bugs.
Greg
GB>>I meant a logic error - as in the user forgot to use a
GB>>DIRECTORY_SEPARATOR and so can't find any of the classes, not an
GB>>obvious PHP error.
OK - then how exactly you want the error message look like? How the engine
is going to guess if it was DIRECTORY_SEPARATOR missing or the class was
genuinely missing?
GB>>Perhaps a better solution is to simply augment the "undefined class XXX"
GB>>method with a brief listing of all the defined __autoload() functions,
GB>>so the user knows where to look for magic bugs.
What, you mean output all autoloading functions? Why? If you defined them,
you know them, if you didn't, you shouldn't count on them to be there
anyway. And what exactly this listing would reveal to you? You couldn't
find a bug just looking on the names.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Stanislav Malyshev wrote:
GB>>I meant a logic error - as in the user forgot to use a
GB>>DIRECTORY_SEPARATOR and so can't find any of the classes, not an
GB>>obvious PHP error.OK - then how exactly you want the error message look like? How the engine
is going to guess if it wasDIRECTORY_SEPARATORmissing or the class was
genuinely missing?GB>>Perhaps a better solution is to simply augment the "undefined class XXX"
GB>>method with a brief listing of all the defined __autoload() functions,
GB>>so the user knows where to look for magic bugs.What, you mean output all autoloading functions? Why? If you defined them,
you know them, if you didn't, you shouldn't count on them to be there
anyway. And what exactly this listing would reveal to you? You couldn't
find a bug just looking on the names.
Stanislav,
Greg probable means something like a stack trace of the autload callbacks
that were called. This will be a nice addition just like Exception stacktraces
are (I wish there were stacktraces for Fatal errors).
Andrey
Andrey Hristov wrote:
Stanislav,
Greg probable means something like a stack trace of the autload callbacks
that were called. This will be a nice addition just like Exception
stacktraces
are (I wish there were stacktraces for Fatal errors).
yes, a stack trace would be ideal - I knew there was a name for that
thing I was describing :)
Greg
Hello Greg,
Monday, April 4, 2005, 2:04:47 PM, you wrote:
Andrey Hristov wrote:
Stanislav,
Greg probable means something like a stack trace of the autload callbacks
that were called. This will be a nice addition just like Exception
stacktraces
are (I wish there were stacktraces for Fatal errors).
yes, a stack trace would be ideal - I knew there was a name for that
thing I was describing :)
Greg
SPl offers a function to check all registered functions. Since a missing
class would require all those functions to fail that's all you need to know.
And i think we can somehow even allow exceptions. I think it actually works
right now already but i have to check....will do so one the flight home
Best regards,
Marcus mailto:mail@marcus-boerger.de
Hello Greg,
Monday, April 4, 2005, 2:04:47 PM, you wrote:
Andrey Hristov wrote:
Stanislav,
Greg probable means something like a stack trace of the autload callbacks
that were called. This will be a nice addition just like Exception
stacktraces
are (I wish there were stacktraces for Fatal errors).
yes, a stack trace would be ideal - I knew there was a name for that
thing I was describing :)
A stack trace is only some additional information that has no real added
information. Also it is not a real stack trace since what you asked is
just a list of functions called at one level and not the trace up to
that part where a class was missing (which would be a stack trace).
After my last commit you can get a stack trace by throwing an exception
in the last called function. To get a list of all functions being called
just check spl_autoload_functions().
A combination of both would require the engine to be changed to be capable
of handling multiple exceptions - which hopefully we do not want. Right
now a second exception while an exception is already pending results in a
fatal error.
--
Best regards,
Marcus mailto:mail@marcus-boerger.de
Marcus Boerger wrote:
Hello Greg,
Monday, April 4, 2005, 2:04:47 PM, you wrote:
Andrey Hristov wrote:
Stanislav,
Greg probable means something like a stack trace of the autload callbacks
that were called. This will be a nice addition just like Exception
stacktraces
are (I wish there were stacktraces for Fatal errors).yes, a stack trace would be ideal - I knew there was a name for that
thing I was describing :)A stack trace is only some additional information that has no real added
information. Also it is not a real stack trace since what you asked is
just a list of functions called at one level and not the trace up to
that part where a class was missing (which would be a stack trace).
I imagined that a failed __autoload() would leave the old on one the
call stack, as if the user had inserted the call to the new __autoload()
before the last closing }.
After my last commit you can get a stack trace by throwing an exception
in the last called function. To get a list of all functions being called
just checkspl_autoload_functions().
The exception solution will only work if the user puts a throw() in
there. The list of functions would be more useful, imo.
A combination of both would require the engine to be changed to be capable
of handling multiple exceptions - which hopefully we do not want. Right
now a second exception while an exception is already pending results in a
fatal error.
I don't think putting exceptions into __autoload is a good idea at all,
the only use exceptions serve is to bubble out of contexts, whereas an
undefined class will simply error out. Simpler is to provide an option
for users to define an error handler that can display the __autoload()
functions used with some kind of listing function, whether it is
spl_autoload_functions() or an engine feature.
Greg
GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload() before the last closing }.
Too much magic, IMO. All you need to know is the list of functions, you
don't need any 'stack' since they do not call each one.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Stanislav Malyshev wrote:
GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload() before the last closing }.Too much magic, IMO. All you need to know is the list of functions, you
don't need any 'stack' since they do not call each one.
Stanislav,
a stack is a list and a list is a stack, right ? :)
Andrey
Hello Andrey,
Tuesday, April 5, 2005, 5:21:17 PM, you wrote:
Stanislav Malyshev wrote:
GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload() before the last closing }.Too much magic, IMO. All you need to know is the list of functions, you
don't need any 'stack' since they do not call each one.
I completeley agree with Stanislav here, way to much magic: The engine
should never fumble around with a trace before making it accessible.Stanislav,
a stack is a list and a list is a stack, right ? :)
Wrong, by list we mean all registered autoload functions which
can be retrived by 'print_r(spl_autoload_functions())' and the
stack trace from main to the autoload call.
--
Best regards,
Marcus mailto:mail@marcus-boerger.de
Marcus Boerger wrote:
Hello Andrey,
Tuesday, April 5, 2005, 5:21:17 PM, you wrote:
Stanislav Malyshev wrote:
GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload() before the last closing }.Too much magic, IMO. All you need to know is the list of functions, you
don't need any 'stack' since they do not call each one.I completeley agree with Stanislav here, way to much magic: The engine
should never fumble around with a trace before making it accessible.Stanislav,
a stack is a list and a list is a stack, right ? :)Wrong, by list we mean all registered autoload functions which
can be retrived by 'print_r(spl_autoload_functions())' and the
stack trace from main to the autoload call.
Marcus,
for the record, he mentioned stack not stacktrace :)
Andrey
Hello Zeev,
Sunday, April 3, 2005, 6:05:22 AM, you wrote:
All,
One problem that became apparent after the introduction of __autoload(), is
that different pieces of code, sometimes coming from different sources, may
want to declare this function in a different way. Today, __autoload() is
treated like any other function, so it's impossible to re-declare it.
Marcus tried to solve it by introducing an __autoload() wrapper in
SPL. Personally I think it's probably not the right way to go, but that's
beside the point right now.
I did not try to get it fixed i just fixed it (dot).
Right from the beginning i said __autoload() is just wrong and we need the
described behavior. However all i got back is that i am just wrong and we
don't need it. And that from everybody. But since SPL already gives all
you mentioned there is no reason to do anything more.
I'll come back here once i have my Montreal slides online which documnets
everthing or i may also find time to do documentation soon.
best regards
marcus
At 11:31 AM 4/3/2005 -0400, Marcus Boerger wrote:
I did not try to get it fixed i just fixed it (dot).
Right from the beginning i said __autoload() is just wrong and we need the
described behavior. However all i got back is that i am just wrong and we
don't need it. And that from everybody. But since SPL already gives all
you mentioned there is no reason to do anything more.I'll come back here once i have my Montreal slides online which documnets
everthing or i may also find time to do documentation soon.
Well I think the point is that you were right that the current way
__autoload() works is not good enough.
I don't think the right solution though is to leave the not-optimal
solution in the engine, and create a solution outside the engine. I think
we should find a way to tune the engine so that it works well. Zeev's
suggestion keeps BC. If there are concerns as far as chaining order are
concerned, I personally don't have a problem supplying an API function
where functions can be added programmatically.
We'd then get the best of both worlds and make it very accessible by everyone.
Andi
I don't think the right solution though is to leave the not-optimal
solution in the engine, and create a solution outside the engine. I think
we should find a way to tune the engine so that it works well. Zeev's
suggestion keeps BC. If there are concerns as far as chaining order are
concerned, I personally don't have a problem supplying an API function
where functions can be added programmatically.
We'd then get the best of both worlds and make it very accessible by everyone.
FWIW, I don't think maintaining BC is super important here. I don't
believe lots of people are using __autoload() currently, and it should
be pretty trivial to migrate to whatever solution we end up with.
I would prefer we concentrate on getting the __autoload() behavior
that we think is right. If we can do both, then that's a win-win, but
we shouldn't let BC get in the way here for the two reasons I outlined
above.
Also, from a timing perspective, if we are modifying __autoload(), I
would suggest that PHP 5.1 would be the correct place to introduce it.
Finally, on the point of "does order matter?" I think order does
matter.
I may want to pull classes from a general framework (such as PEAR)
and also from my own personal set of classes. I don't want to
accidently include a PEAR class that has the same name as my own
class.
I believe Andrey's reference to include_path (or the PATH variable in
your shell) is a good one. What if we said developers can't rely on
the order of their path? The feature would be far less useful because
of clashes.
-adam
--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
I don't think the right solution though is to leave the not-optimal
solution in the engine, and create a solution outside the engine. I think
we should find a way to tune the engine so that it works well. Zeev's
suggestion keeps BC. If there are concerns as far as chaining order are
concerned, I personally don't have a problem supplying an API function
where functions can be added programmatically.
We'd then get the best of both worlds and make it very accessible by everyone.FWIW, I don't think maintaining BC is super important here. I don't
believe lots of people are using __autoload() currently, and it should
be pretty trivial to migrate to whatever solution we end up with.
BC is always important.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
FWIW, I don't think maintaining BC is super important here. I don't
believe lots of people are using __autoload() currently, and it should
be pretty trivial to migrate to whatever solution we end up with.BC is always important.
I didn't say it wasn't important. I said it wasn't "super
important". :)
-adam
--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!