Re: Why change require_once? A brief explanation of motives

Alexey Borzov wrote:

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:

This is the autoload as per the user .. see my updated version I just send to the list.

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

I forgot to wrap things with a class_exists() call along the lines as I explained in my pseudo code variant in response to Philippe.

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?

Alexey, I think you fail to understand that its not a black and white world. Its not about "the RFC sucks" or if you "believe" me or Greg. Its about finding a solution. Labeling things "idiocy" or whatever serves no purpose to this list. It might give you personal gratification. I think we should provide various proven implementations for users that provide different strategies. regards, Lukas