FAQ

On Thu, Feb 4, 2016 at 2:00 AM, Davey Shafik wrote:
On Wednesday, February 3, 2016, Sara Golemon 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.
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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 14 of 17 | next ›
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 3, '16 at 9:03a
activeFeb 6, '16 at 6:11a
posts17
users10
websitephp.net

People

Translate

site design / logo © 2019 Grokbase