There seem to still be some misconceptions about what opcodes are, and therefore what this feature would achieve.
Firstly, PHP opcodes are not native machine code.
To execute PHP opcodes, you need to run the Zend Engine. As far as I know, the only other things that can do anything with opcodes are debugging tools, most of which are compiled on top of Zend Engine anyway.
So opcodes do not make embedding or linking to PHP from other languages or programs any easier. Whether you have PHP source code or opcodes, you will need the Zend Engine to execute them.
Secondly, PHP opcodes are not equivalent to Java bytecode or .Net CIL.
The JVM and .Net runtime were explicitly designed for portability - "compile once, run anywhere". They define a standardised intermediate language, with strong guarantees about compatibility between versions and environments. To repeat: these are not incidental features, they are at the very heart of the design of these technologies.
The Zend Engine in general, and OpCache in particular, has almost the opposite aim: its job is to make code run fast on the current environment. It can and will generate different representations based on factors like:
- Changes added in a the latest build of PHP
- Extensions currently loaded
- Location of the file being compiled (e.g. the
__FILE__and__DIR__constant folding mentioned by Tyson above) - CPU architecture
- Operating system
So opcodes are not, and never will be, a good way to distribute code to multiple targets. If you put opcodes in a PHAR file, that PHAR file is going to be useless to 99.999% of other PHP users, whose environment won't match yours.
Finally, opcodes are not a good way to obfuscate PHP.
Like portability, obfuscation is not a design aim, and it wouldn't make sense to compromise on other aims for that purpose. If you want to obfuscate PHP code, a standalone tool that operates on the PHP source code will be better in almost every way:
- It can be distributed and installed independently of PHP. (You might think built-in tools are better, but they mean slower updates, and a more awkward install process.)
- It will be portable across all systems, and as many versions of PHP as you want.
- It can rename classes, functions, etc which you mark as internal only, by analysing the whole project at once (opcache operates one file at a time).
- It can be configured to strip out things which would normally be available in reflection, like docblock comments.
- It can, if you want, use obfuscation tricks that have a performance penalty.