On Wednesday, February 3, 2016, Sara Golemon <poll...@php.net> wrote:

> > 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.
>

Unfortunately Sara, the types of things you generally have to work around
are minor things, like differences in DOM, or the inability to json_encode
DateTimeImmuteable

I do however like the idea of feature detection - I wonder if perhaps we
could do something where it's done at compile time and therefore minimally
impacts runtime?

Reply via email to