Hi Internals,
especially with (radical) userland API changes coming up in PHP6,
might I suggest something like a ifdef feature which turns blocks of
code into comments?
This would allow framework authors to provide backwards compatibility
with "older" PHP versions while being able to take advantage of new
PHP features.
In theory, it could also be supplied as "update" to the already
existing minor versions (5.4,5.5 and 5.6) so that these versions can
also use the new code.
Marco
--
Marco Schuster
IT-Beratung, Web Development
Blütenstr. 23
80799 München
2014-03-08 23:34 GMT+02:00 Marco Schuster marco@m-s-d.eu:
Hi Internals,
especially with (radical) userland API changes coming up in PHP6,
might I suggest something like a ifdef feature which turns blocks of
code into comments?
This would allow framework authors to provide backwards compatibility
with "older" PHP versions while being able to take advantage of new
PHP features.
In theory, it could also be supplied as "update" to the already
existing minor versions (5.4,5.5 and 5.6) so that these versions can
also use the new code.Marco
Hello Marco.
This really sounds strange. Why? Because you already have all the tools in
userland to do all that since like PHP 4.
You have "function_exists"
http://lv.php.net/manual/en/function.function-exists.php , you have
"phpversion" http://lv.php.net/manual/en/function.phpversion.php, you have
PHP_VERSION_ID constant (details about the constant are in
http://lv.php.net/manual/en/function.phpversion.php too), you have
version_compare http://lv.php.net/manual/en/function.version-compare.php
Sometimes you just need to look up the actual manual...
Arvids.
Hi!
especially with (radical) userland API changes coming up in PHP6,
might I suggest something like a ifdef feature which turns blocks of
code into comments?
How is it supposed to be implemented? PHP has no separate "compile-time"
than can produce significant improvement in performance, like C-like
languages do, and given opcode caching, such conditions should either be
resolved statically - which means limited usability, as you'd have to
drive them off something that you can use no code to define, or use some
logic to resolve them dynamically, which logic would probably take
nearly as much time and space as regular if() would.
This would allow framework authors to provide backwards compatibility
with "older" PHP versions while being able to take advantage of new
PHP features.
This can easily be done by a set of includes and using version checks,
function_exists, class_exists and such. The performance hit in case
those are not needed would be very minimal and probably not warranting
new language construct addition.
In theory, it could also be supplied as "update" to the already
existing minor versions (5.4,5.5 and 5.6) so that these versions can
also use the new code.
Not likely for stable ones. According to our release process, we do not
add language features in old stable versions, and the additions are
limited to bugfixes and small self-contained features. Adding such
feature would hardly qualify as one of those.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 09.03.2014 06:41 schrieb "Stas Malyshev" smalyshev@sugarcrm.com:
How is it supposed to be implemented? PHP has no separate "compile-time"
than can produce significant improvement in performance, like C-like
languages do, and given opcode caching, such conditions should either be
resolved statically - which means limited usability, as you'd have to
drive them off something that you can use no code to define, or use some
logic to resolve them dynamically, which logic would probably take
nearly as much time and space as regular if() would.
Such compile-time optimization, especially regarding opcaches leaving out
entire blocks of code completely for the rest of their livetime, can be
sanely driven, as far as I can see, exactly for the set of constants that
have already been defined at the end of MINIT. A single bit giving that
meta information on the constant, would suffice to signal that possibility.
That would basically be all constants defined by PHP core and loaded
extensions, Which might already be, in my eye, a useful thing to support,
providing dead block elimination for PHP version constant compares, tests
that certain socket flags are present, and so on.
To me (and others when they would use it), it would be even more useful
when a "configurable constants" extension like PHP-Defcon (see github) is
used. We use that to define diverse server-type constants on different
servers all using the same PHP code base.
Now, all that does not need new syntax - "just" a compile time evaluation
of any branchy constant expression regarding "does it use only literals and
constants already defined at the end of MINIT".
Maybe I'm stupid to not know that APC and/or opcache already does that?
Couldn't see it immediately so I thought I'd write the issue down.
best regards
Patrick
hi Marco,
Hi Internals,
especially with (radical) userland API changes coming up in PHP6,
might I suggest something like a ifdef feature which turns blocks of
code into comments?
This would allow framework authors to provide backwards compatibility
with "older" PHP versions while being able to take advantage of new
PHP features.
In theory, it could also be supplied as "update" to the already
existing minor versions (5.4,5.5 and 5.6) so that these versions can
also use the new code.
We had a similar discussion about adding conditional blocks using the
php version some time ago.
One of the main point against adding such feature was that packagers
tools are a better place to deal with that. I agree it won't solve the
multiple files requirement if one project like to use newer syntax
while keeping compatibility with older php versions, but I do not see
that as a bad thing.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org