On 23/07/2014 22:59, Ben Ramsey wrote:
This got me thinking about the whole version number debate. With a language
specification, to what does the version number refer? The state of the language
specification, or the state of a given implementation of the specification?
Right now, the number refers to the state of the PHP Group implementation, and
implementations like HippyVM and HHVM say that they are compatible with Zend
PHP 5.x. Will we version the language specification separately, and individual
releases of various implementations (including the PHP Group implementation)
will state that they are compatible with version X of the specification?
This is exactly what I said in “a lot of questions remain open” in my
previous mail [1]. Taking the example of XML, CSS, HTML, ECMAScript or
other languages (maybe the JVM, I don't know exactly), there is version
numbers for the specification, that are different of the version numbers
of the implementations. Even more, the version of the implementations is
most of the time unknown (what is the version of SpiderMonkey or V8 for
ECMAScript x? We don't really know).
In the case of PHP, this is different because the word “PHP” was
previously (yes, it's done) representing the language **and** the
implementation. Consequently, we can't start with PHP1.
1. A solution would be to start with PHP6 (and 7, I don't know…) for the
specification, and then, the version of the implementations will have no
importance (HHVM1.3, ZendEngine3.0, whatever you want).
2. Another solution is to refer to the PHP version with a “new name”,
something like “PHPx” or “PHPv”, so we will have "PHPx1”, “PHPx2” etc.
3. A final solution I see is to refer to PHP with “PHP1” which will be
equivalent to “PHP6.1”, exactly as Java7 which is in reality Java1.7,
but when they will introduce Java2.x, they will encounter a problem…
My favorite solution is the 2nd one.
Moreover, what about (let's say with PHPx) PHPx1.2.3? Does it make sense
to have x.y.z for a language specification? We don't see it very often.
Actually, x.y is enough I would say (XML1.1, Java1.7 etc.), I don't know
any x.y.z language specification.
Another problem to solve: what about the `php_version` function, the
`PHP_VERSION_ID` constant etc. If an implementation (a VM) respects the
specification, testing the version of the specification does not make
sense anymore, except in edge-cases, so we will really test the version
of language. Do we keep these functions and constants? Do we introduce
new ones? The specification might define the format of some functions
or constants to get the versions of the implementation, for example:
`PHP_VM_VERSION_ID` along with `PHP_VM_NAME` (something similar to what
PHP does with SAPI).
Thoughts?
[1] http://marc.info/?l=php-internals&m=140612071919140&w=2
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
