Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error)
Message-ID: <533142C3.9060908@hoa-project.net>
Date: Tue, 25 Mar 2014 09:48:03 +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> <533089B5.7040504@anderiasch.de>
In-Reply-To: <533089B5.7040504@anderiasch.de>
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 20:38, Florian Anderiasch wrote:
> 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 t=
o
>> promote this standard and invite other actors to collaborate. These la=
st
>> years, PHP has shown a new face, a face of unity and pragmatism (new
>> release process, RFC debates etc.). Such a standardization process wil=
l
>> 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?=

Please, read the email I sent today at 9.31am (GMT+1) [1].


> 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 an=
d
> 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 b=
ug?
I think we have to learn from the past and experiences of other=20
projects. Maybe the best way to write such a specification is to adopt=20
the approach of the CSS Working Group [2] where they have split the=20
specification into modules [3, 4].


> So yes, I don't think there'd be a lot of objection if someone magicall=
y
> 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"
Well. It could be that it was the wrong design ;-) ?
I don't think it will be difficult. php-src will continue to leave as it =

is until we have the first specification draft delivered, and then, for=20
each written and validated specification parts/modules, php-src will=20
adapt its behavior, step by step. It will not be an earthquake=E2=80=A6


Regards.

[1] http://news.php.net/php.internals/73414
[2] http://www.w3.org/Style/CSS/
[3] http://www.w3.org/Style/CSS/current-work
[4] http://www.w3.org/standards/techs/css

--=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/