Hi! > Put simply PHP extensions should only reference the APIs exposed in the > php headers. Zend has its own interface and extensions and since a Zend > Opcode cache is SO intimately coupled with the Zend environment it makes > sense to use a Zend extension to implement this. The whole idea of
OK, I see. Well, the difference between Zend ext and PHP ext is not that big, it's mostly just loading order and couple of hooks, of which I think O+ really uses only op_array_handler, and this for optimization's benefit - so if you separate optimization, I think O+ can live as PHP extension, maybe. Not sure if it's worth the trouble though. > Now to ZEND_INCLUDE_OR_EVAL. My rationale here is that if the admin has > specified a stat=0 (or equiv) option then this is a statement that the > caches content and metadata can be trusted so there is no point in > examining or reading source files. However, in the case of the xxx_once > variants of this instruction, the > ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in > the case of first load opens the source stream. Why? Why not just I see what you mean. I can't think of a reason why they are combined now. Before realpath cache and separate path resolution functions that was the only way to handle paths properly - since path can be resolved differently by different streams, etc. I think giving a fresh look to this API and seeing if we can improve it for 5.6, etc. would probably be a good idea. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
