Re: Rethink CS for require_once?
| From: | Lukas Smith | Date: | Wed, 01 Dec 2004 17:18:58 +0000 |
| Subject: | Re: Rethink CS for require_once? | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-34705@lists.php.net to get a copy of this message | ||
Greg Beaver wrote:
bertrand Gugger wrote:well if all libs dont use autoload then you kill off a large chunk of code that could benefit from autoload. however the actual implementation of the autoload method should be left to the user. we can just provide the necessary pieces. so if we define a common PEAR::loadClass() method we can check if an __autoload() function exists or not. If it exists then we can delegate the job of loading the code to the __autoload() function. regards, LukasHi, I'm puzzled, so I come back to it again, Greg Beaver wrote:yes, exactly. I don't think it is wise to introduce any PEAR-wide dependencies on loading methods. Nothing should hamper the user's ability to write his or her own __autoload() function, as this is an application-level option, and not a package-level option.Hi, I would like to suggest a simple and compelling change into the CS for require_once in PEAR packages.Don't blame if I'm bloody, I try to understand what you suggest. Is it: You want to have all sub "internal" required php to be relative not to the PEAR translation but to the location of the basic requiring pear package ? I retain that user scripts and require of external pckgs MUST still say 'require_once'