On 03/24/2014 05:15 AM, Ivan Enderlin @ Hoa wrote:
Hello :-),
We see more and more PHP interpreters or compilers out there:
* the historical interpreter [1],
* interpreter from Facebook [2],
* interpreter written for .NET [3],
* interpreter written for JVM [4],
* maybe I forgot some of them.
Google App Engine's PHP Interpreter has a few modifications from the core standard. At least one that I know of is that the mail() function is replaced with a dummy function which does not send anything[since your not allowed to make outgoing socket connections].
Deploying an app on GAE, as well as digging into HHVM was the reason for my proposal to add functionality so that the mail() function can be handled as elegantly as opening a stream or storing session data.
Rather then having to code in ugly checks for what php platform your using and what PHP platform your using, it is much simpler to just use the mail() function and leave it up to PHP to allow different types of delivery based on what mail handler is currently active.
Beyond that, I agree that it would be good to generate specs for the system in a better manner. One thing I ran into when trying out HHVM a while back was that it could not handle some non-documented 'features' For example, under PHP it is[or at least was under 5.4] possible to pass a private method for a class to spl_autoload_register. Since the manual specifies that the method passed must be public, that is how HHVM was initially designed - it matched the public spec.
Registering a private method for spl_autoload_register will cause weird and difficult to debug errors is the private method throws an exception. So that would be a good item to decide on precisely what functions and methods can be registered as an autoloader - if private ones should be allowed, then the exception handling has to be fixed. If they should not be allowed, then at some point this "feature" should be removed from the PHP interpreter.