Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73401 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71490 invoked from network); 25 Mar 2014 02:00:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Mar 2014 02:00:07 -0000 Received: from [127.0.0.1] ([127.0.0.1:21624]) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ECSTREAM id B7/E1-60997-723E0335 for ; Mon, 24 Mar 2014 21:00:07 -0500 X-Host-Fingerprint: 204.210.137.32 cpe-204-210-137-32.hvc.res.rr.com Received: from [204.210.137.32] ([204.210.137.32:6676] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AD/B2-02253-B3560335 for ; Mon, 24 Mar 2014 12:02:52 -0500 Message-ID: To: internals@lists.php.net Date: Mon, 24 Mar 2014 13:02:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <532FF7B9.5040700@hoa-project.net> <1395653827.9365.9.camel@guybrush> <1395654744.9365.17.camel@guybrush> <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 X-Posted-By: 204.210.137.32 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 >> 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.