Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.48 as permitted sender)
To: Sara Golemon <pollita@php.net>, Matt Prelude <me@mprelu.de>
References: <CANaX5nf4eDSVaYg=HygRO-vK7r9yAvdhzoTUOFHT1LHUjpQjgw@mail.gmail.com>
 <CA+kxMuQCXB2VssedW9E=kvB4UfM+VbkWFHAZ4BFz9O7cWZA5Ag@mail.gmail.com>
 <56B233C0.10301@mprelu.de>
 <CAESVnVo6dM2N4KuA144pWkGe53ggy_rRF690QViVX5hmCc5D5Q@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <56B27660.60001@gmail.com>
Date: Wed, 3 Feb 2016 13:51:28 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAESVnVo6dM2N4KuA144pWkGe53ggy_rRF690QViVX5hmCc5D5Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Add PHP_ENGINE Constant
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

>> 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

And I think it is the right choice. PHP_VERSION essentially (also) means
the version of the spec and of the implementation. And people do depend
on it (despite better solution being to check for specific feature, but
it's not always easy). I think having also HHVM_VERSION is enough to
both detect HHVM and check for specific quirks if necessary. If you have
another implementation, like Quercus, I'd expect something like
QUERCUS_VERSION.

> 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

Well, the thing there is that the spec does not define the library, and
a lot of things do depend on library. So sometimes PHP_VERSION is also
used to check for something we've added in minor version, and that won't
be in the spec.

> class ReflectionLanguage {
>   public function isSupported($feature): bool;
>   public function variableSyntaxConformance(): string;
>   public function strictTypehints(): bool;
> }

Yes, but would we add there something like "does foo_bar($baz, $zoo)
support second parameter or not yet"? Or "is that annoying bug where
bar_foo didn't support Unicode strings fixed or not?" People use version
for that too.

-- 
Stas Malyshev
smalyshev@gmail.com