Hello Stanislav, Saturday, September 8, 2007, 1:50:24 AM, you wrote:
>> Actually, an autoload handler should never emit errors or throw >> exceptions. With handlers registered through SPL, it is already the >> case. When using an __autoload() functions, raising an error when a >> symbol is not found is useless because we know that the PHP >> interpreter will do it. So, I propose to have PHP ignore any error or > This is a good point - raising errors in chained autoloader makes little > sense since next one in chain might be able to load the class. However, > I am still concerned about the performance impact - exhausting all > autoloading opportunities might be not cheap in big application, and it > would be not nice if people just using something like $foo = new > DateTime() would lose a lot of performance on it. I strive for "if you > don't use it, you don't pay for it" approach - i.e. if you don't have > own DateTime class, you shouldn't have to pay for the possibility of > having one. >> interface. So, an autoload handler like PHK's has to try both. It is > What do you mean by "try both"? Could you explain a bit more on that? I guess the point is that ppl might want to have interfaces use different approach than they want class to. For instance classes get filenames with just the classname followed by '.php' while interfaces might get a prefix 'i_' or a different extension like '.inc'. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
