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