Hi!
>> 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
And I think it is the right choice. PHP_VERSION essentially (also) means
the version of the spec and of the implementation. And people do depend
on it (despite better solution being to check for specific feature, but
it's not always easy). I think having also HHVM_VERSION is enough to
both detect HHVM and check for specific quirks if necessary. If you have
another implementation, like Quercus, I'd expect something like
QUERCUS_VERSION.
> 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
Well, the thing there is that the spec does not define the library, and
a lot of things do depend on library. So sometimes PHP_VERSION is also
used to check for something we've added in minor version, and that won't
be in the spec.
> class ReflectionLanguage {
> public function isSupported($feature): bool;
> public function variableSyntaxConformance(): string;
> public function strictTypehints(): bool;
> }
Yes, but would we add there something like "does foo_bar($baz, $zoo)
support second parameter or not yet"? Or "is that annoying bug where
bar_foo didn't support Unicode strings fixed or not?" People use version
for that too.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
