Kalle,
My use case is for the php7-mysql-shim, some of the error messages I
duplicate and therefore have tests for, are different on HHVM, meaning the
tests fail.
The messages aren't in the spec, so they're not failing to support the
spec, and it's unlikely to affect functionality — which is why I simply
skip the tests on HHVM.
This detection is much harder in Hippy, and who knows what other existing
and future engines.
Also, what happens when we get engines that are good candidates for say,
multithreading, and we want to change application behavior on that engine
automatically.
There are tons of places this _may_ be useful, and there's zero impact to
adding it.
- Davey
On Fri, Sep 9, 2016 at 5:42 PM, Kalle Sommer Nielsen <ka...@php.net> wrote:
> Hi Davey
>
> 2016-09-10 1:49 GMT+02:00 Davey Shafik <da...@php.net>:
> > Hi all,
> >
> > As noted last week, I'm now opening up the vote for adding a PHP Engine
> > Identifier constant to PHP 7.2+ (and more importantly, to the language
> > spec). Additionally, there is a second vote to add corresponding
> > PHP_ENGINE_(*_)VERSION(_ID) constants.
>
> While I understand the reasoning behind it, I do not think that it is
> our problem to solve, whether we do if(defined('HHVM_VERSION')) or
> if(PHP_ENGINE == 'hhvm') seems irrelevant to me. If code are not
> compliant with the spec, then it should be that implementors
> responsibility to make sure that it is resolved imho.
>
> I do not have anything against HHVM or alternative implementations of
> PHP, it rocks, but I think we need to look in other directions, as it
> shouldn't be needed at all to check for what runs your PHP, it should
> _just_ work. For syntax incompatibility, then we can't even filter out
> other implementations with a constant thats executed at runtime
> either, not that I believe it is a major issue, but it is something to
> consider too.
>
> Hence my -1
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
