Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [PREVOTE] PHP Engine Constants »

[PREVOTE] PHP Engine Constants

php.internals

Davey

10 years ago
Hey all, 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 planning 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. The vote will be a straight 50%+1 yes/no vote. - Davey

Fleshgrinder

10 years ago
On 9/1/2016 8:02 PM, Davey Shafik wrote:
> Hey all, > > 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 planning 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. > > The vote will be a straight 50%+1 yes/no vote. > > - Davey >
+1 from my side. What do you think about including a platform and architecture identifier too? const string PHP_ENGINE_PLATFORM = ''; WINDOWS LINUX MACOS CYGWIN FREEBSD SOLARIS ... This would solve all the tricks we see in various code bases that try to determine what platform the current PHP installation is running on, e.g.: if (DIRECTORY_SEPARATOR === '\\') could be replaced with a more readable if (PHP_ENGINE_PLATFORM === 'WINDOWS'). const string PHP_ENGINE_ARCHITECTURE = ''; x86 x64 ia64 arm ... This is not required as often but still needed at some places. This would allow to replace checks like if (PHP_INT_SIZE === 8) with if (PHP_ENGINE_ARCHITECTURE === 'x64').
-- Richard "Fleshgrinder" Fussenegger

Davey

10 years ago
On Thu, Sep 1, 2016 at 12:04 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 9/1/2016 8:02 PM, Davey Shafik wrote: > > Hey all, > > > > 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 > planning 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. > > > > The vote will be a straight 50%+1 yes/no vote. > > > > - Davey > > > > +1 from my side. > > What do you think about including a platform and architecture identifier > too? > > const string PHP_ENGINE_PLATFORM = ''; > > WINDOWS > LINUX > MACOS > CYGWIN > FREEBSD > SOLARIS > ... > > This would solve all the tricks we see in various code bases that try to > determine what platform the current PHP installation is running on, > e.g.: if (DIRECTORY_SEPARATOR === '\\') could be replaced with a more > readable if (PHP_ENGINE_PLATFORM === 'WINDOWS'). > > const string PHP_ENGINE_ARCHITECTURE = ''; > > x86 > x64 > ia64 > arm > ... > > This is not required as often but still needed at some places. This > would allow to replace checks like if (PHP_INT_SIZE === 8) with if > (PHP_ENGINE_ARCHITECTURE === 'x64').
We already have PHP_OS, and architecture is likely too broad to determine specific things like INT size etc. That is, while you may be using things like INT size to determine architecture, the inverse is not necessarily true. I don't think these really fit in with the goal of this RFC, which is more about identifying the spec being implemented in alternative runtimes; while your suggestions would just be part of the spec and would just be in those runtimes like any other feature. - Davey

Andrew Faulds

10 years ago
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 planning 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 foremost alternative implementation. The implications of it are interesting. Currently, PHP doesn't really have 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 version of PHP as, say, “7.1.1”, but instead as just “7.1”, and put “7.1.1” 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. 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 by default. Anyway, that's just a few thoughts of mine.
-- Andrea Faulds https://ajf.me/

Davey

10 years ago
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 planning >> 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 foremost > alternative implementation. > > The implications of it are interesting. Currently, PHP doesn't really have > 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 version > of PHP as, say, “7.1.1”, but instead as just “7.1”, and put “7.1.1” 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 by > 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 === 'hhvm' && PHP_ENGINE_VERSION_ID <= 30813
> Anyway, that's just a few thoughts of mine.
Thanks! - Davey

Dan Ackroyd

10 years ago
On 5 September 2016 at 19:43, Davey Shafik <davey@php.net> wrote:
> > Instead, it would be better to check PHP_ENGINE === > 'hhvm' && PHP_ENGINE_VERSION_ID <= 30813
And then when the next people who want to build an alternative engine come along, they will include this constant, to make their engine as 'compatible' as possible with the current PHP engine. i.e. adding this doesn't provide a way of telling real PHP apart from something that is copying it.
> Then you need to check for HHVM_VERSION
So...that sounds like the correct thing to be checking for. Test for known "almost but not quite PHP" engines, otherwise assume that you're running on real PHP. cheers Dan

Davey

10 years ago
On Tue, Sep 6, 2016 at 1:32 PM, Dan Ackroyd <danack@basereality.com> wrote:
> On 5 September 2016 at 19:43, Davey Shafik <davey@php.net> wrote: > > > > Instead, it would be better to check PHP_ENGINE === > > 'hhvm' && PHP_ENGINE_VERSION_ID <= 30813 > > And then when the next people who want to build an alternative engine > come along, they will include this constant, to make their engine as > 'compatible' as possible with the current PHP engine. > > i.e. adding this doesn't provide a way of telling real PHP apart from > something that is copying it. >
The key to this is that it's part of the spec. If you actually want to follow the spec, you have to implement it this way. If you don't, then you're a bad person. :P
> > Then you need to check for HHVM_VERSION > > So...that sounds like the correct thing to be checking for. Test for > known "almost but not quite PHP" engines, otherwise assume that you're > running on real PHP. >
The problem is also when running on unknown PHP engines. Assumptions are terrible things. - Davey

Dan Ackroyd

10 years ago
On 6 September 2016 at 22:39, Davey Shafik <davey@php.net> wrote:
> > > The key to this is that it's part of the spec. If you actually want to > follow the spec, you have to implement it this way. If you don't, then > you're a bad person. :P
Perhaps you can make the RFC text be clearer then. e.g. to this bit: "PHP_ENGINE — A simple string denoting the runtime engine, e.g. php or hhvm" add something like "The contents of the string MUST be unique to the runtime engine being used." because currently, to me, there's nothing in the RFC that actually says how it needs to be implemented by other engines. cheers Dan

Davey

10 years ago
On Tue, Sep 6, 2016 at 2:51 PM, Dan Ackroyd <danack@basereality.com> wrote:
> On 6 September 2016 at 22:39, Davey Shafik <davey@php.net> wrote: > > > > > > The key to this is that it's part of the spec. If you actually want to > > follow the spec, you have to implement it this way. If you don't, then > > you're a bad person. :P > > > Perhaps you can make the RFC text be clearer then. e.g. to this bit: > > "PHP_ENGINE — A simple string denoting the runtime engine, e.g. php or > hhvm" > > add something like "The contents of the string MUST be unique to the > runtime engine being used." > > because currently, to me, there's nothing in the RFC that actually > says how it needs to be implemented by other engines.
I'm not sure how to make this more clear:
> This RFC proposes to add a new constant that explicitly denotes the
engine being used, and more importantly makes it's use as such part of the language spec. I will try, but any suggestions are welcome - Davey

Stas Malyshev

10 years ago
Hi!
> And then when the next people who want to build an alternative engine > come along, they will include this constant, to make their engine as > 'compatible' as possible with the current PHP engine.
Yes, same things that happened to user-agent string in browsers may start happening here. But I still think that doesn't invalidate idea of having user-agent identification. So we just need to make it very clear what we expect from people that set this string *and* from people that use this string (e.g. using "if(PHP_ENGINE !== 'php') die()" is discouraged since then everybody would set their PHP_ENGINE to php just so that software would work) - then we can hope it won't be abused too much...
-- Stas Malyshev smalyshev@gmail.com