Hi Stas :-),
On 24/03/2014 23:36, Stas Malyshev wrote:
Hi!
All these projects are great for PHP! Yes they are! But, most of these
implementations, interpreters, extensions wrappers etc., are incomplete
or propose extra features that is not in the historical interpreter. The
need of a PHP specification/standard is more and more important:
language syntax, semantics, features, extensions API, etc., must be
specified in order to see more collaborations and quality tools.
Having an agreed upon spec would be a nice thing to have. If adopted
would definitely be useful for some, though I don't see it as absolute
necessity, it would definitely help in many things.
That said, while I agree that many of the third-party implementations of
PHP-style languages extend and remove the features, I don't see how
having standard would help that. It is obvious that those features are
added or removed for a reason - somebody needed feature X and found it
hard or unworthy their time to implement feature Y. How exactly having
document saying "PHP should have Y but not X" would help that?
The specification can also be a common denominator between all the implementations. Something like a subset of the php-src which includes the syntax, the semantics, the tool and the standard library (ext/core, ext/standard, ext/stream, ext/spl and some others). Maybe the standard library of php-src could also be “refactored” (I prefer “re-architectured”) in order to be clearer what is standard and what is not from the user point of view. However, such points will be clarified during the specification process.
Even from compatibility POV - i.e. the way to ensure app running on
PHP-like engine X would run on another PHP-like engine Y - it is much
more useful to have a good coverage test suite than a document. But
again, that should not prevent you from creating such a document.
There's no harm in doing it, and if it comes out good, then a lot of
good can follow.
Actually, my idea was to provide a specification along with an “abstract” (understand implementation-free) tests suite. This is how the majority of projects work. And this will be complementary of the php-src, HHVM etc. test suites (but it would have to be exhaustive, and this is will require a lot of time, that's why I have proposed in [1] to split the specification in different modules).
Yes it will reveal some leaks in the historical interpreter. Yes the
I would allow myself some advice here - if you want people here be more
excited about this, drop the "historical" word. If you need the special
name for the PHP engine developed by the php.net group in order to
emphasize its distinction, call it "official" or "original" or "php.net"
(that if "the PHP engine" is not enough for some reason). I know it
looks like nitpicking, but when we're talking both about
community-building and about defining things, words matter.
Yes definitively :-). In french (my first speaking language), this word does not sound too pejorative, my mistake! Johannes used the term “prime implementation” which is good also, but “official” sounds good enough for me too.
If a new interpreter provides a nice feature, then, a discussion can
start to update the standard, but if there is no one, which interpreter
will be chosen by the user? If there is a standard, we can compare
Nothing prevents one right now from submitting RFC for a nice feature
that exists in PHP-like interpreter X but does not exist in PHP. Having
standard wouldn't change much in that regard.
The specification will define what will be standard and what will not be. For Web technologies, this is exactly the same thing. We have standards/specifications, and implementations. One vendor proposes a new features through an implementation and a specification proposal. It is discussed at the specification level and then valided or not. If it is validateed, then other vendors will update their implementation to respect the specification. If it is not validated, then either they review their proposal or they give up or at last they keep it as “private”. And this last option is not bad at all: if they need this feature, well, they implement it and that's good. If a user would like such a feature, then it will use this implementation. But if someone is making a framework, a set of libraries, a big tool, that is intented to be used by every PHP user, then, it will develop in regards of the standard/specification. That's how things work. And if a feature in a specification implementation appears to be very attractive for users, then the “specification consortium” could revise its position. This is a living process, made by humans for humans!
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
Thoughts?
If you're ready to start such project, go ahead and do it. I personally
wish you all the luck.
Thank you. I really would like to start it, maybe in few weeks/months. Things are clear in my head, maybe I could draft something in few weeks.