Re: Why change require_once? A brief explanation of motives

Alexey Borzov wrote:

Hi, Lukas Kahwe Smith wrote:

What are you arguing against? Is having to define that __autoload() function really worth not providing this flexibility?

Failure to __autoload() a class always results in a fatal error, exceptions thrown in __autoload() cannot be caught. You didn't provide sample code Philippe asked you about [1] and I suppose that's because you simply can't.

====== Bar.php ======= class Bar { public static function factory($driver) {

    $class_name = 'Bar_'.$driver;
    if (__autoload($class_name)) {
      return new $class_name();
    }
    throw new Exception('unable to load');

} } ====== Bar/Meat.php ======= class Bar_Meat { } ====== foo.php ======= function __autoload($class_name) { // if the user has some kind of preference about how to confirm that the file // exists, or how syntax errors should be handled when __autoload() is called // directly, then he could implement those here return include str_replace('_', '/', $class_name).'.php'; } $bar = Bar::factory('Meat'); var_dump(get_class($bar)); $bar = Bar::factory('Meaty'); var_dump(get_class($bar)); ========== This gives me the output: Bar_Meat + 2 Warnings and an Exception Now the "ugly" part in all of this, is something we have been debating on this list before without a proper agreement. The first one is the fact that in order to prevent those warnings, you would have to suppress the include with an @ or you would need to attempt to find the file in the file system first, which is harder than one would hope for when relying on the include_path, since internals does not think we need an include_path search parameter in file_exists() like is available in fopen(). The work arounds to this are either not truely reliable or are inefficient and of course this is all open to race conditions. The other issue are potential syntax errors in the file to be included. The good news is that the user is now in control over how this should be dealt with inside the __autoload(). The bad news is that the user would need to implement all of this special handling for factory loaders in the generic implementation that gets call in all other cases as well, and there is no way to pass in any parameter to __autoload() to differentiate explicit loading attempts compared to implicit ones caused by making an instance of a not yet defined class. In the end I again prefer the added flexibility, since instead of all the back and forth in the past, where the PEAR developers were essentially the ones deciding what hack to do, its now in the application developers hands (though we can still provide him with reliable implementations for this choice). regards, Lukas