Re: Re: autoload, include_once naming conventions

> Lukas Smith wrote: > >> Basically what if we would replace all (require|include)_once calls with >> a static PEAR method. This method would get a class name passed and > > I was just talking to Helgi on IRC and he voiced concerns that if that > static method will be part of the PEAR base class that alot of people > will be against making this a requirement. > > The solution would be to use a PEAR_Util class or something like that > instead that resides in a separate file. Yeah tho I'm against a new class because of the reasons you mention below. PEAR.php is what we want! ;) > However I think that this concern is mood. The cost of parsing the > PEAR.php file is obviously fixed regardless of how many times you > include it. Obviously there is still the cost of the include_once. > However my proposal aims to cut down on the total number of include_once > calls already. Furthermore its likely that some package already will > need to include PEAR.php either for the error handling, to extend from > PEAR or to use things like loadExtension(). So adding yet another file > will likely only increase the costs as now you need to include two files > in most real time scenarios (versus synthetic benchmarks). Yes like I said later it's to getting people that aren't using PEAR.php or lazy load it to use it by default :) I will find it very odd if people won't start to use it and do require PEAR.php at top of the base class for error handling or what ever :) > Generally the point of PEAR is to provide our core infrastructure. So > infrastructure should go there. In all the "lets not include PEAR.php" > frenzy people keep coming up with code and cludges that we would never > need if we just accept that any request that makes heavy use of PEAR > packages will likely include PEAR.php anyways. > > I would also like to highlight once again why I extend from PEAR and > PEAR_Error in MDB[2]. This enables me to use things like expectError(), > setErrorHandler() etc. These are very powerful tools on PHP4 to ensure > that no error goes unnoticed and you still have the option of handling > errors locally. I find them even superior to exceptions but that is > besides the point. PEAR is still very much dependent on PHP4 code for > quite some time. Also extending from PEAR_Error enables users to > determine that with the error objects returned by MDB[2] they can use > the MDB[2] error codes to handle specific errors codes in their code. Error_Stack requires PEAR.php, right ? So packages using that will get this "function" or what ever it will be ... Anyhoo, our battle will not be getting this kinda function to PEAR, it will be to make certain developers use it ;) - Helgi