Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73371 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78886 invoked from network); 24 Mar 2014 09:48:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Mar 2014 09:48:44 -0000 Authentication-Results: pb1.pair.com header.from=ivan.enderlin@hoa-project.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ivan.enderlin@hoa-project.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error) X-PHP-List-Original-Sender: ivan.enderlin@hoa-project.net X-Host-Fingerprint: 95.130.10.56 host1.ip6-networks.net Received: from [95.130.10.56] ([95.130.10.56:54590] helo=host1.ip6-networks.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 07/62-63501-B7FFF235 for ; Mon, 24 Mar 2014 04:48:44 -0500 Received: from Hwhost2.local (184-175.106-92.cust.bluewin.ch [92.106.175.184]) by host1.ip6-networks.net (Postfix) with ESMTPSA id 33A93609D7 for ; Mon, 24 Mar 2014 10:48:41 +0100 (CET) Message-ID: <532FFF78.6080504@hoa-project.net> Date: Mon, 24 Mar 2014 10:48:40 +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> <1395653827.9365.9.camel@guybrush> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] PHP Specification From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa") On 24/03/2014 10:42, Pierre Joye wrote: > On Mon, Mar 24, 2014 at 10:37 AM, Johannes Schl=C3=BCter > wrote: >> On Mon, 2014-03-24 at 10:15 +0100, Ivan Enderlin @ Hoa wrote: >> [snip] >> >>> Finally, I think that internal@ is responsible to start such a >>> standardization process because this group has made the historical >>> interpreter. >> It is building the reference implementation. If other implementations >> add new features they can and they can propose it for inclusion in the= >> reference implementation by which it becomes part of the language >> definition. While old parts of the implementation are only documented = in >> code and reference documentation form the RFC process provides more >> architectural of new features. > Agreed on the contributions process, however: > > Ivan is talking about specifications, an implementation follows a > given specification, not the other way 'round. A well written > specification greatly simplify documentations, implementation(s) and > testing, to name only a few advantages. +1. You have understood me. > That being said, I find very disturbing the total lack of interest > from historical (from a time pov, not activity) core developers in the > next major version. I don't know the reason. It is related to the vision/goal of PHP, to the = code? Without an answer to this question, we can't fix it. > Most drastic changes around PHP happen outside > PHP, many features our users are looking for are implemented outside > the core while we keep arguing about the needs of these features. This > is not a good thing. I deeply think that a specification will gather people around the same=20 goal. RFC already do this job, but we need to go further. --=20 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/