Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
Message-ID: <5330E321.50109@gmail.com>
Date: Mon, 24 Mar 2014 22:00:01 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <532FF7B9.5040700@hoa-project.net>
In-Reply-To: <532FF7B9.5040700@hoa-project.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: PHP Specification
From: garyamort@gmail.com (Gary Mort)

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.