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.