Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49156
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain openmv.com from 64.15.152.204 cause and error)
To: <internals@lists.php.net>
Date: Wed, 28 Jul 2010 20:54:40 -0400
Message-ID: <001e01cb2eb8$a0928c50$e1b7a4f0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001F_01CB2E97.1980EC50"
Thread-Index: AcsuuJ9V1dWjexgNTre4B7MBqWEzmA==
Content-Language: en-ca
Subject: Zend Extension - zend_compile_file - interoperability?
From: jbondc@openmv.com ("Jonathan Bond-Caron")

------=_NextPart_000_001F_01CB2E97.1980EC50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I've starting playing around with the zend engine, 

is there any hope / plans  for better interoperability with how
zend_compile_file() should be extended? 

The goal being to reduce the amount of  "X is not compatible with Y". 

 

It would be possible to separate extensions in two categories and provide
hooks (without breaking BC):

 

# Bytecode loaders / optimizers / dumpers (zend optimizer, ioncube loader,
vld, etc.)

HOOKS: zend_compile_file, zend_compile_string, zend_execute

 

# Bytecode cache (apc, xcache, etc.)

HOOKS: zend_opc_get, zend_opc_put

 

Internally (Zend/zend.c, ext/phar/phar.c, ext/spl/php_spl.c, etc..)  use
zend_opc_compile_file() ~

 

zend_op_array * opc _compile_file(zend_file_handle *file_handle, int
lifetime, int type TSRMLS_DC)

{

                zend_op_array *retval=NULL;

 

                if( zend_opc_get(file_handle->filename, retval) )

                                return retval;

 

                retval = zend_compile_file(file_handle, type);

 

               zend_opc_put(file_handle->filename, lifetime, retval);

 

                return retval;

}

 

zend_opc_get() and zend_opc_put() would just be stub functions that do
nothing, op code caches would change these methods

 

If there's positive feedback, I can turn this into a RFC and put more work
into it


------=_NextPart_000_001F_01CB2E97.1980EC50--