Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73390 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33269 invoked from network); 24 Mar 2014 19:38:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Mar 2014 19:38:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=ml@anderiasch.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=ml@anderiasch.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain anderiasch.de from 81.169.138.148 cause and error) X-PHP-List-Original-Sender: ml@anderiasch.de X-Host-Fingerprint: 81.169.138.148 ares.art-core.org Received: from [81.169.138.148] ([81.169.138.148:56422] helo=ares.art-core.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D7/95-02253-9B980335 for ; Mon, 24 Mar 2014 14:38:34 -0500 Received: from [172.16.23.4] (francisco.art-core.org [93.190.68.29]) by ares.art-core.org (mail.art-core.org) with ESMTPSA id 992492EE251; Mon, 24 Mar 2014 20:38:30 +0100 (CET) Message-ID: <533089B5.7040504@anderiasch.de> Date: Mon, 24 Mar 2014 20:38:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Thunderbird/29.0a2 MIME-Version: 1.0 To: "Ivan Enderlin @ Hoa" , 'internals' References: <532FF7B9.5040700@hoa-project.net> In-Reply-To: <532FF7B9.5040700@hoa-project.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHP Specification From: ml@anderiasch.de (Florian Anderiasch) On 03/24/2014 10:15 AM, Ivan Enderlin @ Hoa wrote: [...] > Finally, I think that internal@ is responsible to start such a > standardization process because this group has made the historical > interpreter. In addition, I think that internal@ is also responsible to > promote this standard and invite other actors to collaborate. These last > years, PHP has shown a new face, a face of unity and pragmatism (new > release process, RFC debates etc.). Such a standardization process will > be strong and can really put PHP forward. Hi, I just did a quick skim of some of the specs you linked, this is what came out: * ECMAScript - 258 pages * C99 - 552 pages * Java - 780 pages * Ocaml - No PDF, but it looks digestible (syntax only) Sooo, while I wouldn't object to a spec per se, I don't think a simple "hey we need this" is in any way feasible. Where would you even start? Syntax? Make sense of PHP's parser grammar? If you look at the state of the wiki, the amount of verifiable up to date technical documentation is in a quite sorry state (when you think about a history of ~20 years) - that is not to say I don't approve of the recent efforts to fix this problem. Another point is that PHP is evolving faster than ever in the past, release cycles are actually quite short - how can you "freeze" stuff and even begin to commit to a timeframe of even a few months to write down this spec. Then who decides what is working as intended and what is a bug? So yes, I don't think there'd be a lot of objection if someone magically delivered parts of a language spec that is accurate to the current release (let's say 5.6 for now) - but who will do it? PHP's design has always been "fix your own itch, commit it, and as long as it doesn't interfer too much, it's good" Cheers, Florian