Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73404
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.45 as permitted sender)
Message-ID: <5330E32A.8090605@gmail.com>
Date: Mon, 24 Mar 2014 22:00:10 -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>	 <1395653827.9365.9.camel@guybrush>	 <CAEZPtU59+g+YhsAU61u43BPPRoVg77DjUopV59AJiri+SU8b8w@mail.gmail.com>	 <1395654744.9365.17.camel@guybrush>	 <CAEZPtU664TnSu2F6rOaZcZAWDU=aoPekTFkhP=4Ry65zsw-pBQ@mail.gmail.com> <1395655474.9365.25.camel@guybrush>
In-Reply-To: <1395655474.9365.25.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP Specification
From: garyamort@gmail.com (Gary Mort)

On 03/24/2014 06:04 AM, Johannes Schlüter wrote:
> On Mon, 2014-03-24 at 10:55 +0100, Pierre Joye wrote:
>> On Mon, Mar 24, 2014 at 10:52 AM, Johannes Schlüter
>> <johannes@schlueters.de> wrote:
>>
>>> In my opinion it is a good thing that PHP is powerful enough to enable
>>> frameworks etc. to innovate around the core language. The core language
>>> has to be a reliable and stable.
>>
>> Agreed, but I was not clear. I refer to core features like what we can
>> find in hhvm, hack, more recently the JVM compiler or similar
>> projects. Many features which have nothing to do with the engine they
>> use should have been available in the core since long.
>
> If anybody (being a contributor to a clone or some "user") sees anything
> in any implementation that they want to be part of PHP they can under
> the RFC process.
>
> If anybody thinks there is need for a specification they can start
> writing it and look for help and review.

What would be the process for that?  The RFC process covers adding new 
features and removing deprecated features.

The documentation process covers documenting how to use certain features.

Neither of these processes seem to be a direct fit for specifying how 
certain features should handle undocumented features.

If the RFC process is the correct one to follow for that, that would be 
great.   From there it would then be up to those want to spend the time 
to create the RFC itself and then it would be welcome on this list to 
propose/advocate for it?

Note: this same issue has also occurred with gcc.   As the Clang 
compiler gains popularity, the Clang developers have been running test 
compiles of popular open source c/c++ code with it and they have 
discovered hundreds of bugs in those projects.  Because of 
undocumented/broken features in gcc the source for those projects 
compiles and runs anyway.  Obviously if gcc claims to be a "standards 
compliant" compiler then if it is allowing code which is not standards 
compliant to compile without generating any warnings gcc is 'broken'. 
However, they are naturally reluctant to "fix" a bug which will then 
break other people's projects.

Alternative implementations are great for discovering bugs in the 
reference implementation.