[RFC] Add PHP_ENGINE Constant

Currently, HippyVM doesn't even have a version constant. Because it's
trying to pretend to be PHP. Having a "YOU MUST FILL THESE CONSTANTS WITH
YOUR OWN RUNTIMES DATA" in the spec is intended to help that situation.

Right now, there's no way to tell what version of HippyVM you're running
on, and to even check that you're using Hippy you need to check for
E_HIPPY_WARN.

We have a chance to standardize, and "mandate" that the information is
exposed explicitly, and done so consistently.

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

It seems like the main thing this RFC would change is that you could
easily do “if ($engine !== ‘php’)” - but for almost all the examples I can
think of, and yours, what’s actually needed is if "($engine ===
‘specific_engine_that_needs_a_workaround’)”, so I don’t see a benefit over
using HHVM_VERSION or similar.

The one exception I can think of is if someone’s reimplementing phpinfo()
or similar.

Regards,

• Fred

Fred Emmott wrote on 03/02/2016 22:14:

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

It seems like the main thing this RFC would change is that you could easily do “if ($engine !== ‘php’)” - but for almost all the examples I can think of, and yours, what’s actually needed is if "($engine === ‘specific_engine_that_needs_a_workaround’)”, so I don’t see a benefit over using HHVM_VERSION or similar.

The one exception I can think of is if someone’s reimplementing phpinfo() or similar.

Maybe what's actually needed is not something in the PHP spec itself,
but a PHP equivalent of modernizr (https://modernizr.com/) - a library
with a set of feature detections which bypass the whole question of
"real PHP" or needing to know the exact quirks of every implementation.
It would also be much easier to maintain and extend if it existed
outside of any implementation, rather than needing every implementation
to keep up with a growing list of requirements [first feature to detect:
is the feature detection API present? ;)]

It could perhaps take the form of a set of unit tests which you run as
part of a build process that then writes out a profile of the current
environment. This would allow you to detect even things which cause
fatal errors on some implementations, by triggering the error in a
sub-process, and would be more efficient than probing them at runtime.

Regards,

Rowan Collins
[IMSoP]

As an aside, having this kind of #ifdef type stuff also allows us to write
forward compatible scripts without worrying about invalid syntax breaking
older versions.

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.

I am also really not convinced we need a PHP_ENGINE_* set of
constants. It defeats the purpose of these constants.

Each non php.net implementation could (should?) have a
<implementation> and <implementation><version> constants, for
instance, HHVM and HHVM_VERSIONS* constants. These constants can then
be used to do the required work-around for bugs or to use
implementation specific features.

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?

This could be what you actually need. A #ifdef equivalent for PHP. I
remember a discussion about adding these features to the core to allow
to enable/disable portions of a script at the parsing/compilation
level. Doing so allows mixing codes being valid for various
implementations inside a same file. It is especially important for
features using syntax not compatible with a php.net's PHP
specification (for instance).

I am not very keen about that either as I prefer to use separate
files. However it seems to be where we could move forward for these
kind of needs? parser/compilation time constants or expression (like
HAVE_FOO in C for example but only defined by the respective engine
and maybe extensions) as well as at runtime (as normal PHP constants).
Just a thought :)

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

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?

This could be what you actually need. A #ifdef equivalent for PHP. I
remember a discussion about adding these features to the core to allow
to enable/disable portions of a script at the parsing/compilation
level. Doing so allows mixing codes being valid for various
implementations inside a same file. It is especially important for
features using syntax not compatible with a php.net's PHP
specification (for instance).

This usually results in some half-hearted attempts followed by "just
use gcc's preprocessor for that". :)

-Sara