> De : Pierre Joye [mailto:pierre....@gmail.com] > > A proof of concept, IRC log, I am lazy :) > > <Pierre> benjamin, Derick > https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4 > https://gist.github.com/pierrejoye/0859e3702ceb3bb652b6 > https://gist.github.com/pierrejoye/544e60d8994094c55583 > <Pierre> too slow internet for a fork & PR > <Pierre> but it works now. Add PHP_BUILTIN_SCRIPT(date, > PHP_EXT_DIR(date)/date.php) to config.m4, and call manually > zend_execute_script in RINIT, could be easier to do it in a register > function, inside MINIT and let the engine do it on RINIT, actually > cleaner, but this patch is only a prrof of concept to play with
Thanks for this. I thought you were opposed to bundling PHP code in extension... :) I prefer the solution where the extension execute the script(s) in RINIT or at any time, instead of registering scripts in the core and let the core trigger script execution. The main reason is that executing EVERY scripts in RINIT is just one use case among many others. The problem I see with zend_execute_string() is the relationship with opcode caches, because the filename you provide is not a real filename. When an opcode cache receives such a name, it will analyze it as a valid plain file name and it will try to stat() it for mtime, which will probably fail... Actually, the opcode cache has no way to understand what's going on here. That's why I proposed to use a stream-wrapper. It would imply a registration mechanism to ensure path unicity but it would allow opcode caching. And opcode caching is most important here, especially for code executed systematically at RINIT time. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
