Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
Message-ID: <5330E334.7060109@gmail.com>
Date: Mon, 24 Mar 2014 22:00:20 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <532FF7B9.5040700@hoa-project.net> <DD864C7C-6497-411A-9815-36D7662B2846@ajf.me> <5330582B.1020604@hoa-project.net> <5330661B.80202@garfieldtech.com>
In-Reply-To: <5330661B.80202@garfieldtech.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP Specification
From: garyamort@gmail.com (Gary Mort)

On 03/24/2014 01:06 PM, Larry Garfield wrote:
> This has been discussed before in the PHP-next-major context.  A
> language or protocol can either be defined canonically by a
> specification or a reference implementation; it is impossible for it to
> be defined by both.  (Even if they match perfectly, which is almost
> unheard of, one of them is still the Authoritative Source of Answers(tm).)
>
> PHP is currently implementation-defined; that is, the answer to "what is
> PHP supposed to do?" is always "whatever php-src does right now".  Even
> if everyone thinks that's a bug, it means it's technically an API change
> to impact php-src's behavior.  It also makes alternate implementations
> much harder.
>
> A spec-defined language/protocol is easier to evolve, and easier to
> build alternate implementations for.  In general I believe that to be a
> far superior approach.  It is, however, totally not simple to shift from
> an implementation to specification approach; I can't imagine it could be
> done without nominal API changes in edge cases, no matter how hard we try.
>
> Which is exactly why PHP-next-major (6, 7, whatever it's called) would
> be the ideal time, really the only time, to make that transition.

Trying to write a "PHP Specification" that covers everything seems like 
a mountain of a task.

Why not let it BE both?  IE the PHP Spec can be the authoritive word on 
how it should behave for the items covered by the spec.  Anything not
covered by the spec is defined in the Reference implementation.

When undocumented features/bugs are discovered, open a RFC to define the 
specification.  A specification RFC does not need to match how the 
reference behaves today, it can define it as how it should behave.  If 
the RFC spec passes by vote, then if someone wants to open an RFC to 
modify the reference to match the spec, they can, and the voting process 
can determine what version that change will occur in.

Even though the RFC process has matured and it is believed that current 
RFC's are of better clarity and that php-src matches those RFC's, I'd 
bet money that it is possible to find at least one edge case where the 
RFC specifies something different from what php-src is actually doing. 
As such, even recent RFC's cannot be considered specifications - if 
someone wants to make them such they have to re-submit them.

This also means that those who are writing alternative PHP 
implementations can easily submit their understandings as PHP 
specification RFC's and they can do so if it is important to them.