> I think Dan raises some interesting points, although I think zend_version()
> is often used for feature detection so they try to put a zend version in
> there to be helpful i.e. HHVM x.y.z === PHP a.b (feature-wise).
>
That's exactly why PHP_VERSION is faked in HHVM. Because that's how
users use it. Essentially, we're treating PHP_VERSION as "PHP
language specification version X.Y" So for example, hhvm 3.12.0
conforms to phplang-spec 7.0.0 so it defines HHVM_VERSION to tell what
it is, while PHP_VERSION exists for all those scripts that were
written under the assumption that there's only one PHP runtime.
I would actually suggest that if something like this RFC goes through,
we formally define PHP_VERSION in exactly that way. As a language
specification conformance advertisement. PHP_ENGINE_VERSION would be
the build ID for the actual runtime implementation. In the case of
the reference implementation, these numbers would be identical, so
there would be no effective change. In the case of other
implementations, they'd differ. For example on HHVM you'd have:
PHP_VERSION=7.0.0, PHP_ENGINE=hhvm, PHP_ENGINE_VERSION=3.12.0
All that said, I'm not convinced we *need* explicitly enumerated
constants like PHP_ENGINE, but for that 0.1% of scripts that care who
they're running under, it would certainly unify that detection in a
useful way.
To the question of "are we just replicating browser detection and all
its problems?", I'd offer that perhaps the solution lies not in more
constants, but in Reflection. For example:
class ReflectionLanguage {
public function isSupported($feature): bool;
public function variableSyntaxConformance(): string;
public function strictTypehints(): bool;
}
Some of these would be compiler constant-ish, others might be per-file
(like strictTypeHints()).
^^ The above is a half-baked idea, please alter/destroy it at will.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
