Hello Gary and Larry :-),
On 25/03/2014 03:00, Gary Mort wrote:
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.
Oh yeah…
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.
I am not sure to understand your proposal well, but instead of producing a full complete specification at first, we should focus on important features than other implementations do not support. Typically, the fact the php binary reads from its stdin is missing most of the time.
I imagine to start the specification at different levels:
* the syntax, which is not easy since PHP grammars is ambigious but it's feasible in a reasonable time,
* the semantics, very very important, it will describe how data are represented, objects etc., how they behaves, it will clarify a lot of things
* the tool, i.e. the PHP architecture through SAPI, one of the most clever feature of PHP,
* the extension, how are they split in different directories, how to load them etc. (still from the user point of view)
* then the standard library, which includes ext/core, ext/standard, ext/stream etc.
The goal is not, at first, to specify the behavior of all functions. This would be totally crazy. PHP has a big tests suite to check that. Before, the most important thing (for me) is to specify the langage (syntax, semantics and tool). This is a good start and a nice task since types, auto-boxing, generators etc., will be described in those parts.
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.
Exactly. RFC will still be the point where to propose new features.
--
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/