On Thu, Feb 4, 2016 at 2:00 AM, Davey Shafik <da...@php.net> wrote:
> 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.
>>
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
