Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73416
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error)
Message-ID: <53313FF6.5070205@hoa-project.net>
Date: Tue, 25 Mar 2014 09:36:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0a2
MIME-Version: 1.0
To: internals@lists.php.net
References: <532FF7B9.5040700@hoa-project.net> <08.72.02253.9AE50335@pb1.pair.com>
In-Reply-To: <08.72.02253.9AE50335@pb1.pair.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP Specification
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

On 24/03/2014 17:34, Gary Mort wrote:
> 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.
This is exactly those kinds of things that must be specified. And I am 
even not sure that PHP is consistent with this ;-).

-- 
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/