Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91086
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANaX5ncq5JX704G66wWcYOWMKDkkd=CqQuEQ2DT5a32qiM1P0A@mail.gmail.com>
References: <CANaX5nf4eDSVaYg=HygRO-vK7r9yAvdhzoTUOFHT1LHUjpQjgw@mail.gmail.com>
	<CA+kxMuQCXB2VssedW9E=kvB4UfM+VbkWFHAZ4BFz9O7cWZA5Ag@mail.gmail.com>
	<56B233C0.10301@mprelu.de>
	<CAESVnVo6dM2N4KuA144pWkGe53ggy_rRF690QViVX5hmCc5D5Q@mail.gmail.com>
	<CANaX5ncq5JX704G66wWcYOWMKDkkd=CqQuEQ2DT5a32qiM1P0A@mail.gmail.com>
Date: Fri, 5 Feb 2016 23:20:44 +0700
Message-ID: <CAEZPtU5_Eg994UEb1T0N3XxmW9T0QhfXd96du-ATMzJKe0GT5w@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: Sara Golemon <pollita@php.net>, Matt Prelude <me@mprelu.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC] Add PHP_ENGINE Constant
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Feb 4, 2016 at 2:00 AM, Davey Shafik <davey@php.net> wrote:
> On Wednesday, February 3, 2016, Sara Golemon <pollita@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