Re: Why change require_once? A brief explanation of motives

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');

} }

Is this the __autoload() as defined in user's code or the __autoload() defined in PEAR2_Load class, which, according to Greg, we aren't providing:

#3 means we are never going to have another base class named PEAR2 or PEAR2_Loader - the inflexibility will make embedding PEAR2 libraries harder than it is to embed PEAR libraries now.

? In any case, your much touted "flexibility" is now mysteriously vanishing, 'cause even if I use the glorious allofthefilesthatidon'tneed.php approach, I still need the __autoload() defined. Now please explain how I am expected to run unit tests and usage examples without mangling them.

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).

And Greg tells us that we won't provide such implementations. Whom exactly must I believe here?