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
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
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
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/
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
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
Instead, it would be better to check PHP_ENGINE ===
'hhvm' && PHP_ENGINE_VERSION_ID <= 30813And 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
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
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. :PPerhaps 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
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