Re: Rethink CS for require_once?

Lukas Smith wrote:

Greg Beaver wrote:

Andrew Nagy wrote:

I don't know if this has been discussed before, but what about using just require for internal packages and require_once for external? Rasmus Lerdorf mentioned at a PHP conference that require_once is really slow and should be avoided at all costs. Considering the app programmer most likely will not be including files buried deep with in a pear package, this may be more beneficial?

I think the disadvantages outweigh the benefits - remember, I'm not looking for a performance gain, that's just an added benefit in some situations. Most important is the security of knowing that internal files will only come from one place.

I still dont see how your solution will work around the issues stated in Stig's post that Alan linked to. Also remember that different packages will include a given package. So you also need to take into account that its not always the user that includes a given package.

The problem Stig is talking about would only come about if a package is included as both require_once 'DB/mysql.php'; and as require_once dirname(__FILE__) . '/mysql.php'; As I said, if any file *can* be used by itself, then it is disqualified from the dirname(__FILE__) rule. Otherwise, the only inclusion code will be either: require_once 'DB/mysql.php'; or require_once dirname(__FILE__) . '/mysql.php'; and the file inclusion would only be accessible through a method of DB (factory or whatnot). A better example: require_once 'PEAR/Command/Config.php'; is illegal because it is included in the PEAR package as dirname(__FILE__) . '/Command/Config.php'; It can be access only through the PEAR_Command object, which is included by require_once 'PEAR/Command.php'; and you include the command with PEAR_Command::registerCommands() There is no conflict, because it is not possible to include the file in both ways (is not allowed by convention). In the past, the proposal was to use dirname(__FILE__) for every internal file. This is impossible, it can only be limited to every *private* internal file. Greg