Re: Comments about PHPTAL package proposal?

On 19.04.2009, at 17:56, Greg Beaver wrote:

This is needed to avoid mix-up of files from PEAR and other installations of PHPTAL, e.g.: include "my/framework/libs/PHPTAL.php"; won't work properly without enforced path prefix. There's same problem when running test suite. Does PEAR have solution to this?

Yes. Look at how phpDocumentor handles this. You provide a stub file that modifies include_path which other installations then use.

phpDocumentor does:

set_include_path(get_include_path() . PATH_SEPARATOR . dirname(dirname(__FILE__)));

which doesn't solve the problem - if PEAR dir is somewhere in the path, it will still be used instead of specified directory. And adding of directories earlier in include_path is unsafe - e.g. applications having "config.php" could accidentally include PEAR's Config package on case-insensitive filesystem (I have run into this problem myself :)

Incidentally, it is never wise to use constructs like: include CONSTNAME . '/path/to/blah.php'; because opcode caches will never cache your code at compile-time, as the path cannot be safely resolved until run-time. It makes your code intrinsically slower even with an opcode cache.

I've tested this with APC and it seems to work fine (APC's stats report hits for these files). Because include_path can be changed anytime, "constant" paths aren't constant either. One more reason why I like PHPTAL_DIR prefix is that it's an absolute directory and PHP doesn't need to stat() directories in include_path to load these files. As far as I understood, this was recommended by Rasmus in his Drupalcon keynote (http://www.archive.org/details/simple_is_hard) -- regards, Kornel