Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.160.182 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <CAESVnVo6dM2N4KuA144pWkGe53ggy_rRF690QViVX5hmCc5D5Q@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>
Date: Wed, 3 Feb 2016 14:00:48 -0500
Message-ID: <CANaX5ncq5JX704G66wWcYOWMKDkkd=CqQuEQ2DT5a32qiM1P0A@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Matt Prelude <me@mprelu.de>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0b752e7810fc052ae23c39
Subject: Re: [RFC] Add PHP_ENGINE Constant
From: davey@php.net (Davey Shafik)

--94eb2c0b752e7810fc052ae23c39
Content-Type: text/plain; charset=UTF-8

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.
>

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?

--94eb2c0b752e7810fc052ae23c39--