Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91066
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56B233C0.10301@mprelu.de>
References: <CANaX5nf4eDSVaYg=HygRO-vK7r9yAvdhzoTUOFHT1LHUjpQjgw@mail.gmail.com>
 <CA+kxMuQCXB2VssedW9E=kvB4UfM+VbkWFHAZ4BFz9O7cWZA5Ag@mail.gmail.com> <56B233C0.10301@mprelu.de>
Date: Wed, 3 Feb 2016 12:17:15 -0500
Message-ID: <CAF+u_BxCyJroorht=pQfU6myOvMynsMmEnHY=xLnyCkTzwQiHw@mail.gmail.com>
To: Matt Prelude <me@mprelu.de>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a114382ce440b14052ae0cb4e
Subject: Re: [PHP-DEV] [RFC] Add PHP_ENGINE Constant
From: kinncj@gmail.com (=?UTF-8?B?S2lubiBKdWxpw6Nv?=)

--001a114382ce440b14052ae0cb4e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 3, 2016 at 12:07 PM, Matt Prelude <me@mprelu.de> wrote:

> Hi,
>
> On 03/02/16 16:54, Dan Ackroyd wrote:
>
>> On 3 February 2016 at 09:03, Davey Shafik <davey@php.net> wrote:
>>
>>> Hi all,
>>>
>>> It's actually very difficult to be able to reliably determine that you
>>> are
>>> running the _real_ PHP runtime and not something mimicking it.
>>>
>> The underlying problem seems to be caused by HHVM deliberately
>> 'faking' the results of calls to zend_version() and the existing
>> constants. What is there to stop any other PHP implementations from
>> returning 'fake' data for that function or these new constants?
>>
>> And just to play devils advocate, why isn't this a problem that should
>> be solved in those other versions of PHP? They're the ones re-using
>> version strings and so causing confusion.
>>
>> I can see how this could be useful....I just can't see how this would
>> be a permanent solution to the problem. As someone else said, this
>> sounds like the old detecting browsers via "user agent headers" for
>> browser detection. That became a complete nightmare as browsers kept
>> imitating each other, and so the rules about strings became less and
>> less useful.
>>
>> Perhaps it might be helpful to justify the RFC, if you can give some
>> more context as to why code needs to know about what VM it is running
>> on?
>>
>> cheers
>> Dan
>>
>> 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 =3D=3D=3D PHP a.b
> (feature-wise).
>
> I can see how this could be useful. Would get my +1 if I had a vote.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


I agree with Andreas when:

And in the end the goal would be to not adapt the code to different
> runtine-engines but to adapt the runtime engines to run the code in the
> same manner. That's what the language-specification is there for.


If the motivation is:

> I want to bring forward a very simple RFC to help solve an issue I had th=
is
> week of writing unit tests that take into account differing behaviors in
> PHP and HHVM.


I suggest the following
http://hhvm.com/blog/2393/hhvm-2-3-0-and-travis-ci

and instead of introducing one more constant, you could easily use

*if (defined('HHVM_VERSION')) {}*

--=20
*--*
*Kinn Coelho Juli=C3=A3o*
*Toronto - ON/Canada*

--001a114382ce440b14052ae0cb4e--