Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95669
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.179 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <CF.96.45301.727BDC75@pb1.pair.com>
References: <CANaX5nf8kUBhaM0QEwbJWdt+0yzrXEHR3oqpHYFarJd1DAgiTw@mail.gmail.com>
 <CF.96.45301.727BDC75@pb1.pair.com>
Date: Mon, 5 Sep 2016 11:43:55 -0700
Message-ID: <CANaX5nfF31WDrEZO-f08r0PCSfV8tg5RjWvKgH77svYvmzS=Ww@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114fe61af997d1053bc70fc0
Subject: Re: [PHP-DEV] Re: [PREVOTE] PHP Engine Constants
From: davey@php.net (Davey Shafik)

--001a114fe61af997d1053bc70fc0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 5, 2016 at 11:19 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Davey,
>
> Davey Shafik wrote:
>
>> A while back I brought a small RFC to internals, that proposed a set of
>> constants that were specifically for alternative implementations to
>> identify themselves as such if they want to conform to the spec.
>>
>> https://wiki.php.net/rfc/php_engine_constant
>>
>> There were some folks who didn't like it, but nobody suggested different
>> implementations, just didn't feel it was necessary. As such, I'm plannin=
g
>> to
>> bring it to a vote next week - this is simply a heads up as it's been a
>> while
>> and I want to give a chance for any objections other than not wanting it
>> to
>> be voiced before I open it up for voting.
>>
>
> This is an interesting idea. Have you asked the HHVM team what they think
> about it? Their input is probably more important than ours, as the foremo=
st
> alternative implementation.
>
> The implications of it are interesting. Currently, PHP doesn't really hav=
e
> any separation between the current version of the PHP interpreter and the
> version of the language. Despite the specification efforts, PHP versions
> are effectively defined by the main implementation.
>
> Would this RFC be changing that, decoupling the version of PHP, the
> language, from PHP, the interpreter? Would we no longer report the versio=
n
> of PHP as, say, =E2=80=9C7.1.1=E2=80=9D, but instead as just =E2=80=9C7.1=
=E2=80=9D, and put =E2=80=9C7.1.1=E2=80=9D as the
> engine version? The micro version, at least with the modern release
> process, is only meaningful for the PHP interpreter, and not other
> implementations.
>

As per the RFC, the PHP_*_VERSION (and related constants) and the
PHP_ENGINE_*_VERSION constants would be the same for php.net.


> Also, isn't there a danger of code sniffing for the engine? I wouldn't be
> entirely surprised if, in future, HHVM might start pretending to be PHP b=
y
> default.
>

This is actually the problem right now, they already _do_ this, despite not
being 100% to spec. Then you need to check for HHVM_VERSION and work around
those differences. Instead, it would be better to check PHP_ENGINE =3D=3D=
=3D
'hhvm' && PHP_ENGINE_VERSION_ID <=3D 30813


> Anyway, that's just a few thoughts of mine.


Thanks!

- Davey

--001a114fe61af997d1053bc70fc0--