Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91089
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.161.182 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <CAEZPtU5_Eg994UEb1T0N3XxmW9T0QhfXd96du-ATMzJKe0GT5w@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>
	<CAEZPtU5_Eg994UEb1T0N3XxmW9T0QhfXd96du-ATMzJKe0GT5w@mail.gmail.com>
Date: Fri, 5 Feb 2016 13:35:56 -0500
Message-ID: <CANaX5nc6mEC+tK97=uUrBDm21TN-FAFCmKVwy_zZoyrFwj1tYA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Sara Golemon <pollita@php.net>, Matt Prelude <me@mprelu.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c07e598380429052b0a1f53
Subject: Re: [PHP-DEV] Re: [RFC] Add PHP_ENGINE Constant
From: davey@php.net (Davey Shafik)

--94eb2c07e598380429052b0a1f53
Content-Type: text/plain; charset=UTF-8

As an aside, having this kind of #ifdef type stuff also allows us to write
forward compatible scripts without worrying about invalid syntax breaking
older versions.

On Fri, Feb 5, 2016 at 11:20 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> 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
>

--94eb2c07e598380429052b0a1f53--