Re: PHP Specification

From: Date: Tue, 25 Mar 2014 02:00:10 +0000
Subject: Re: PHP Specification
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
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
<[email protected]> 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.

Thread (53 messages)

« previous php.internals (#73404) next »