Hi all,
I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.php
Something like
<?php
declare(php_version>='5.6.0');
// or PHP_VERSION_ID? using = as minimum as it could be a little faster
// and no change in declare() syntax.
declare(php_version=50600);
If version mismatches, raise compile error and exit. Something like
Compile error: PHP 5.6.0 or later is required to compile script. Your PHP
version is 5.x.x.
The same thing can be done by version_compare() and die(), but it does not
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when it is
included, not when it is executed. I wouldn't write version_compare() and
die() for libraries, but I may use it if it's a declare(). If this is
adopted widely, it may help transition to higher versions hoping users to
consider compile error more seriously.
Issue would be current behavior for unsupported declaration.
$ php -r "declare(php_version=050600);"
Warning: Unsupported declare 'php_version' in Command line code on line 1
It does not raise E_ERROR, but E_WARNING.
Just an idea.
Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Just an idea.
Any comments?
It looks like #define and #ifdef to me, which are achieved by packages
(composer), or testing using the php version constants.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Pierre,
Just an idea.
Any comments?It looks like #define and #ifdef to me, which are achieved by packages
(composer), or testing using the php version constants.
I agree.
Good packaging system should be able to handle dependency ;)
I'm not sure if this is good for us.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.phpSomething like
<?php
declare(php_version>='5.6.0');
// or PHP_VERSION_ID? using = as minimum as it could be a little faster
// and no change in declare() syntax.
declare(php_version=50600);If version mismatches, raise compile error and exit. Something like
Compile error: PHP 5.6.0 or later is required to compile script. Your PHP
version is 5.x.x.The same thing can be done by
version_compare()and die(), but it does not
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when it is
included, not when it is executed. I wouldn't writeversion_compare()and
die() for libraries, but I may use it if it's a declare(). If this is
adopted widely, it may help transition to higher versions hoping users to
consider compile error more seriously.Issue would be current behavior for unsupported declaration.
$ php -r "declare(php_version=050600);"
Warning: Unsupported declare 'php_version' in Command line code on line 1
It does not raise E_ERROR, but E_WARNING.Just an idea.
Any comments?
It may be good to have Zend API to register required library versions for
modules. For example,
declare('libxxx_version'=1.0.0);
If it does not much, failed at include.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
It may be good to have Zend API to register required library versions for
modules. For example,declare('libxxx_version'=1.0.0);
If it does not much, failed at include.
As Pierre said, dependency managers are indeed the current way of solving
this.
I think there was some previous discussion about cleaner usage of semver
(or similar approaches) in the extensions though, since some of the
extensions actually have inconsistent or hardly recognizable versioning.
Marco Pivetta
Hi!
The same thing can be done by
version_compare()and die(), but it does not
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when it is
Why not? That's what PHP does - executing scripts.
included, not when it is executed. I wouldn't write
version_compare()and
I don't understand - what is the difference? In PHP including and
executing is the same thing.
I think version_compare works just fine.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Mon, Feb 3, 2014 at 4:57 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
The same thing can be done by
version_compare()and die(), but it does
not
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when it isWhy not? That's what PHP does - executing scripts.
included, not when it is executed. I wouldn't write
version_compare()andI don't understand - what is the difference? In PHP including and
executing is the same thing.I think version_compare works just fine.
I works, but it requires CPU time for it and evaluation is delayed at
run time, not compile time. Isn't it nice to know requirement is not met?
We may extend declare() more. For example, loaded extensions.
declare(module='pgsql,openssl');
With this, we could eliminate code like
if (!extension_loaded('foo')) {
die('You need foo module');
}
if (!extension_loaded('bar')) {
die('You need bar module');
}
With opcache loaded extension check may be completely skipped.
Evaluation at compile time and run time differs.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
The same thing can be done by
version_compare()and die(), but it does
not
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when it isWhy not? That's what PHP does - executing scripts.
included, not when it is executed. I wouldn't write
version_compare()andI don't understand - what is the difference? In PHP including and
executing is the same thing.I think version_compare works just fine.
I works, but it requires CPU time for it and evaluation is delayed at
run time, not compile time. Isn't it nice to know requirement is not met?We may extend declare() more. For example, loaded extensions.
declare(module='pgsql,openssl');
With this, we could eliminate code like
if (!extension_loaded('foo')) {
die('You need foo module');
}
if (!extension_loaded('bar')) {
die('You need bar module');
}With opcache loaded extension check may be completely skipped.
Evaluation at compile time and run time differs.
I don't see how one can eliminate checking if a module is available. I do not
load MySQL on my systems so if someone tries to run a script requiring MySQL
they need a warning that it's not available. The build of PHP running ensures
that the available built in modules are of the right version, but it's the third
party libraries that I need to ensure are compatible with the version of PHP I'm
trying to run, and that the necessary extensions for that library are loaded.
Stuff updated to PHP5.5 may not work on the systems that are still running
PHP5.4 for compatibility reasons ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
Yasuo Ohgaki wrote:
The same thing can be done by
version_compare()and die(), but it doesnot
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when
it isWhy not? That's what PHP does - executing scripts.
included, not when it is executed. I wouldn't write
version_compare()andI don't understand - what is the difference? In PHP including and
executing is the same thing.I think version_compare works just fine.
I works, but it requires CPU time for it and evaluation is delayed at
run time, not compile time. Isn't it nice to know requirement is not met?We may extend declare() more. For example, loaded extensions.
declare(module='pgsql,openssl');
With this, we could eliminate code like
if (!extension_loaded('foo')) {
die('You need foo module');
}
if (!extension_loaded('bar')) {
die('You need bar module');
}With opcache loaded extension check may be completely skipped.
Evaluation at compile time and run time differs.
I don't see how one can eliminate checking if a module is available. I do
not load MySQL on my systems so if someone tries to run a script requiring
MySQL they need a warning that it's not available. The build of PHP running
ensures that the available built in modules are of the right version, but
it's the third party libraries that I need to ensure are compatible with
the version of PHP I'm trying to run, and that the necessary extensions for
that library are loaded. Stuff updated to PHP5.5 may not work on the
systems that are still running PHP5.4 for compatibility reasons
declare() is evaluated at compile time. It's not a usual function, but a
Zend engine directive. Therefore, it can be used for
declare(encoding='SJIS') which declare to compiler used encoding.
Since it is evaluated at compile time, run time check is not needed at all
when byte code cache is used.
There are many code out there checks if (!extention_loaded(foo')) die('You
need foo'). This is waste of CPU resources once it is checked. These
requirements for scripts may be evaluated at compile time and script runs a
little faster.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
There are many code out there checks if (!extention_loaded(foo')) die('You
need foo'). This is waste of CPU resources once it is checked. These
requirements for scripts may be evaluated at compile time and script runs a
little faster.
Managing requirements is a job for package manager, like composer, not
language compiler, IMO.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Tue, Feb 4, 2014 at 4:42 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
There are many code out there checks if (!extention_loaded(foo'))
die('You
need foo'). This is waste of CPU resources once it is checked. These
requirements for scripts may be evaluated at compile time and script
runs a
little faster.Managing requirements is a job for package manager, like composer, not
language compiler, IMO.
I agree that good package manager should manage requirements. However, once
code is installed, package manager will not check requirements. (Package
manager could be made to execute requirement checks at any time, though)
Therefore, there would be developers embed environmental checks to make
sure not to die with function not found, etc.
In addition to this, there would be SCL for RHEL7 and there are some tools
like phpenv. Installing PHP does not have to be executing PHP. Even if
there is good package manager, compile time requirement check is nice to
have. It's nice to have and it's not must have, though.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Stas,
On Tue, Feb 4, 2014 at 4:42 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
There are many code out there checks if (!extention_loaded(foo'))
die('You
need foo'). This is waste of CPU resources once it is checked. These
requirements for scripts may be evaluated at compile time and script
runs a
little faster.Managing requirements is a job for package manager, like composer, not
language compiler, IMO.I agree that good package manager should manage requirements. However, once
code is installed, package manager will not check requirements. (Package
manager could be made to execute requirement checks at any time, though)
Therefore, there would be developers embed environmental checks to make
sure not to die with function not found, etc.In addition to this, there would be SCL for RHEL7 and there are some tools
like phpenv. Installing PHP does not have to be executing PHP. Even if
there is good package manager, compile time requirement check is nice to
have. It's nice to have and it's not must have, though.Regards,
I have to agree with Stas and Sara on this one. This is not the job of
the language syntax. This is the package manager's job; once the code
is installed (not compiled, installed), you shouldn't be changing your
version anyway without knowing what you're doing / verifying on a test
system anyway.
If this were more like Javascript's "use strict", where it affected the
parsing rules of that file, that would at least be useful (if
potentially mind-bendingly painful for the engine; no I'm not suggesting
we do that). But a shortcut for if (version_compare()) die; is not
needed, and that would be a dumb way to go about implementing version
requirements in the first place.
--Larry Garfield
Hi Larry,
On Tue, Feb 4, 2014 at 9:34 AM, Larry Garfield larry@garfieldtech.comwrote:
Hi Stas,
On Tue, Feb 4, 2014 at 4:42 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:
There are many code out there checks if (!extention_loaded(foo'))
die('You
need foo'). This is waste of CPU resources once it is checked. These
requirements for scripts may be evaluated at compile time and scriptruns a
little faster.
Managing requirements is a job for package manager, like composer, not
language compiler, IMO.I agree that good package manager should manage requirements. However,
once
code is installed, package manager will not check requirements. (Package
manager could be made to execute requirement checks at any time, though)
Therefore, there would be developers embed environmental checks to make
sure not to die with function not found, etc.In addition to this, there would be SCL for RHEL7 and there are some tools
like phpenv. Installing PHP does not have to be executing PHP. Even if
there is good package manager, compile time requirement check is nice to
have. It's nice to have and it's not must have, though.Regards,
I have to agree with Stas and Sara on this one. This is not the job of
the language syntax. This is the package manager's job; once the code is
installed (not compiled, installed), you shouldn't be changing your version
anyway without knowing what you're doing / verifying on a test system
anyway.If this were more like Javascript's "use strict", where it affected the
parsing rules of that file, that would at least be useful (if potentially
mind-bendingly painful for the engine; no I'm not suggesting we do that).
But a shortcut for if (version_compare()) die; is not needed, and that
would be a dumb way to go about implementing version requirements in the
first place.
This assumption is not valid as I already wrote.
There will be SCL in RHEL7 and there are tools like phpenv.
Installing PHP does not have to be executing PHP.
Version and module requirement checks are popular and I
don't think it is dumb at all. It is dumb that if script didn't
work as it should be due to version mismatch, isn't it?
BTW, it is not a short cut of version check, but "elimination of
run time check overheads". Many people don't understand
what declare() is, it seems.
declare() is compiler directive, NOT a function. Thus it could
instruct what compiler should do at compile time. Since declare()
is compiler directive, compiler may omit byte code for declare
block. Therefore, run time overheads of declare block may be
eliminated with byte code cache.
Isn't checking requirements over and over a waste of resources?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I have to agree with Stas and Sara on this one. This is not the job of
the language syntax. This is the package manager's job; once the code is
installed (not compiled, installed), you shouldn't be changing your version
anyway without knowing what you're doing / verifying on a test system
anyway.If this were more like Javascript's "use strict", where it affected the
parsing rules of that file, that would at least be useful (if potentially
mind-bendingly painful for the engine; no I'm not suggesting we do that).
But a shortcut for if (version_compare()) die; is not needed, and that
would be a dumb way to go about implementing version requirements in the
first place.This assumption is not valid as I already wrote.
There will be SCL in RHEL7 and there are tools like phpenv.
Installing PHP does not have to be executing PHP.
I don't know what SCL is, nor what phpenv is. Thus "installing PHP does
not have to be executing PHP" makes little sense to me as a sentence.
Version and module requirement checks are popular and I
don't think it is dumb at all. It is dumb that if script didn't
work as it should be due to version mismatch, isn't it?
Well usually it will fatal anyway if it's written for a too-new
version. I know software has version checks in it; Drupal (the project
I work on primarily) has had a version check in it for years... but in
the installer, not in arbitrary non-installer files.
BTW, it is not a short cut of version check, but "elimination of
run time check overheads". Many people don't understand
what declare() is, it seems.declare() is compiler directive, NOT a function. Thus it could
instruct what compiler should do at compile time. Since declare()
is compiler directive, compiler may omit byte code for declare
block. Therefore, run time overheads of declare block may be
eliminated with byte code cache.
I can think of exactly one use case for compiling or not compiling a
given file depending on the version, and that's for function backports
(like the old PHP_Compat library, or the backport of the password hash
functions from PHP 5.5.) Those are trivial enough to just wrap the
require statement in a version_compare(). Or, really, the opcode
overhead of that compared to the size of a typical code base these days
is probably negligible.
Isn't checking requirements over and over a waste of resources?
Yes. So don't do it. :-) Really, I have no clue what the use case is here.
--Larry Garfield
Hi Larry,
On Tue, Feb 4, 2014 at 3:34 PM, Larry Garfield larry@garfieldtech.comwrote:
I have to agree with Stas and Sara on this one. This is not the job of
the language syntax. This is the package manager's job; once the code is
installed (not compiled, installed), you shouldn't be changing your
version
anyway without knowing what you're doing / verifying on a test system
anyway.If this were more like Javascript's "use strict", where it affected the
parsing rules of that file, that would at least be useful (if potentially
mind-bendingly painful for the engine; no I'm not suggesting we do that).
But a shortcut for if (version_compare()) die; is not needed, and that
would be a dumb way to go about implementing version requirements in the
first place.This assumption is not valid as I already wrote.
There will be SCL in RHEL7 and there are tools like phpenv.
Installing PHP does not have to be executing PHP.I don't know what SCL is, nor what phpenv is. Thus "installing PHP does
not have to be executing PHP" makes little sense to me as a sentence.
Both SCL and phpenv (or like) provides multiple PHP versions installed on
the same system. Users are easily switch PHP version to be executed. SCL
allows to use multiple versions at the same time, too.
Version and module requirement checks are popular and I
don't think it is dumb at all. It is dumb that if script didn't
work as it should be due to version mismatch, isn't it?Well usually it will fatal anyway if it's written for a too-new version.
I know software has version checks in it; Drupal (the project I work on
primarily) has had a version check in it for years... but in the installer,
not in arbitrary non-installer files.
For application developers, this is the way I would recommend.
BTW, it is not a short cut of version check, but "elimination of
run time check overheads". Many people don't understand
what declare() is, it seems.declare() is compiler directive, NOT a function. Thus it could
instruct what compiler should do at compile time. Since declare()
is compiler directive, compiler may omit byte code for declare
block. Therefore, run time overheads of declare block may be
eliminated with byte code cache.I can think of exactly one use case for compiling or not compiling a given
file depending on the version, and that's for function backports (like the
old PHP_Compat library, or the backport of the password hash functions from
PHP 5.5.) Those are trivial enough to just wrap the require statement in a
version_compare(). Or, really, the opcode overhead of that compared to the
size of a typical code base these days is probably negligible.Isn't checking requirements over and over a waste of resources?
Yes. So don't do it. :-) Really, I have no clue what the use case is here.
For library developers, it's not simple like applications.
Developers would like to specify environment. However, almost all library
would not have a flag if the environment is checked or not. They may specify
supported environment in a document. However, we know that users just
ignore documents if it seems it runs OK.
Developers have 3 options
- Do nothing. Just let it die or fail.
- Provide compatibility check script separately.
- Embed compatibility code in it.
First option is many libraries adopting which is not ideal, but it's good
for
performance. Second may be ignored for the same reason as documentation.
Third option is preferred way to make sure, but it may require unwanted
overheads. If package manager supports compatibility check function or
definition, it must be evaluated as packager specifies.
With declare(), it could be solved nicely with byte code cache. It's also
important that it fails when script is included, no need to evaluate it
with specified manner and/or at run time. It's as simple as including
script
and user know what's wrong immediately. Package manager could be
simpler also.
I only see Pros for this. Is there Cons? Rather than "it can be done this
way"?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
Since it is evaluated at compile time, run time check is not needed at all when
byte code cache is used.There are many code out there checks if (!extention_loaded(foo')) die('You need
foo'). This is waste of CPU resources once it is checked. These requirements for
scripts may be evaluated at compile time and script runs a little faster.
And if the system you are running no longer has your 'byte code cache'? I'm
still running eaccelerator as it's the base for all the legacy systems.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
Yasuo Ohgaki wrote:
Since it is evaluated at compile time, run time check is not needed at
all when
byte code cache is used.There are many code out there checks if (!extention_loaded(foo'))
die('You need
foo'). This is waste of CPU resources once it is checked. These
requirements for
scripts may be evaluated at compile time and script runs a little faster.And if the system you are running no longer has your 'byte code cache'?
I'm still running eaccelerator as it's the base for all the legacy systems.
I don't think type of byte code cache matters.
I could be wrong. Anyone?
BTW, if you use legacy system with legacy code, there would not be
declare('requirements') or like. If there is, you get E_WARNING.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Am 03.02.2014 11:56 schrieb "Yasuo Ohgaki" yohgaki@ohgaki.net:
We may extend declare() more. For example, loaded extensions.
declare(module='pgsql,openssl');
With opcache loaded extension check may be completely skipped.
I like this.
It would be even more useful to me - kind of a more structured #ifdef - if
A) it would work at the block level, not failing, but eliding the block:
declare(module='redis') {
use redis server
}
(instead of a class_exists check with the associated runtime overhead, both
in execution time and opcache memory usage
B) it would support testing for constants
declare(const='ADMIN_SERVER') { ... }
declare(const_false='DEVELOPMENT_SERVER') { ... }
which would really be a plus for us, using MINIT time constants provided by
the defcon extension (http://github.com/infusion/PHP-Defcon)
best regards
Patrick
Am 03.02.2014 12:28 schrieb "Patrick Schaaf" bof@bof.de:
B) it would support testing for constants
declare(const='ADMIN_SERVER') { ... }
declare(const_false='DEVELOPMENT_SERVER') { ... }which would really be a plus for us, using MINIT time constants provided
by the defcon extension (http://github.com/infusion/PHP-Defcon)
For this use case it might be useful if an extension could simply extend
declare with additional keywords, and effect that code elision as a
reaction to the keyword / check being used and done at compile time.
best regards
Patrick
Hi all,
We may extend declare() more. For example, loaded extensions.
declare(module='pgsql,openssl');
With this, we could eliminate code like
if (!extension_loaded('foo')) {
die('You need foo module');
}
if (!extension_loaded('bar')) {
die('You need bar module');
}With opcache loaded extension check may be completely skipped.
Evaluation at compile time and run time differs.
Similar thing could be achieved with new assert() w/o any overheads.
https://wiki.php.net/rfc/expectations
assert('version_compare(PHP_VERSION, "5.5.0", ">=")', 'You need PHP 5.5.0
or later');
Since assert() only accepts expression, it might be nice to have
declare('assert') {
if (!extension_loaded('foo')) {
echo 'You need foo module';
return FALSE;
}
if (!extension_loaded('bar')) {
echo 'You need bar module';
return FALSE
}
return TRUE;
}
Usual PHP code might be easier to write complex assertion.
It may be possible to share most of the new assertion code.
Just an idea.
What do you think Dmitry?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Yasuo,
I don't think PHP needs new language constructs for assertions.
Actually, the code from your example may be implemented as two calls to
assert().
assert(extension_loaded('foo'), 'You need foo module');
assert(extension_loaded('bar'), 'You need bar module');
I think it's much clear then inventing new syntax.
With Joe's proposal these asserts might be completely eliminated.
And it's backward and forward compatible :)
BTW: I didn't follow all the discussion, so I may miss some points.
Thanks. Dmitry.
Hi all,
We may extend declare() more. For example, loaded extensions.
declare(module='pgsql,openssl');
With this, we could eliminate code like
if (!extension_loaded('foo')) {
die('You need foo module');
}
if (!extension_loaded('bar')) {
die('You need bar module');
}With opcache loaded extension check may be completely skipped.
Evaluation at compile time and run time differs.
Similar thing could be achieved with new
assert()w/o any overheads.https://wiki.php.net/rfc/expectations
assert('version_compare(PHP_VERSION, "5.5.0", ">=")', 'You need PHP 5.5.0
or later');Since
assert()only accepts expression, it might be nice to havedeclare('assert') {
if (!extension_loaded('foo')) {
echo 'You need foo module';
return FALSE;
}
if (!extension_loaded('bar')) {
echo 'You need bar module';
returnFALSE
}
return TRUE;
}Usual PHP code might be easier to write complex assertion.
It may be possible to share most of the new assertion code.Just an idea.
What do you think Dmitry?Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Dmitry,
I don't think PHP needs new language constructs for assertions.
Actually, the code from your example may be implemented as two calls to
assert().assert(extension_loaded('foo'), 'You need foo module');
assert(extension_loaded('bar'), 'You need bar module');I think it's much clear then inventing new syntax.
With Joe's proposal these asserts might be completely eliminated.
And it's backward and forward compatible :)BTW: I didn't follow all the discussion, so I may miss some points.
Thank you for reply.
Since new assert() could be eliminate runtime overheads, it may be the
way to go. Regarding assert(), it seems current assert() is inconsistent
for function calls.
Function call works
php > function f() {return FALSE;}
php > assert(f());
Warning: assert(): Assertion failed in php shell code on line 1
Closure does not
php > assert(function() {return FALSE;});
php >
Closure is a valid expression and it should be allowed. IMO.
Allowing callable as 1st parameter makes behavior consistent.
Closure is useful to keep clean name space.
Could you consider this for new assert?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Dmitry,
I don't think PHP needs new language constructs for assertions.
Actually, the code from your example may be implemented as two calls to
assert().assert(extension_loaded('foo'), 'You need foo module');
assert(extension_loaded('bar'), 'You need bar module');I think it's much clear then inventing new syntax.
With Joe's proposal these asserts might be completely eliminated.
And it's backward and forward compatible :)BTW: I didn't follow all the discussion, so I may miss some points.
Thank you for reply.
Since new
assert()could be eliminate runtime overheads, it may be the
way to go. Regardingassert(), it seems currentassert()is inconsistent
for function calls.Function call works
php > function f() {return FALSE;}
php > assert(f());Warning:
assert(): Assertion failed in php shell code on line 1Closure does not
php > assert(function() {return FALSE;});
php >Closure is a valid expression and it should be allowed. IMO.
Yeah, closure is a valid expression but it doesn't tell that closure has to
be called.
assert("f"); // doesn't call f() as well.
So I don't see inconsistency.
Allowing callable as 1st parameter makes behavior consistent.
Closure is useful to keep clean name space.
Could you consider this for new assert?
I'm not sure it's related to assert(). PHP misses construct to create and
call closure in one expression.
So currently we can't write:
assert(function() {return FALSE;}());
but we can write:
$f = function() {return FALSE;};
assert($f());
Thanks. Dmitry.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Dmitry,
but we can write:
$f = function() {return FALSE;};
assert($f());
I'll use this form, if assert() does not support direct closure call.
Direct call seems cleaner to me.
assert(function() {
// Do complex assertion here.
};
Users are used to this form because of JavaScript popularity.
It's a small difference, but I hope new assert() supports this :)
Regards,
P.S. Thank you for the declare(pre/post_hook) comment. I'll look
into VM when I have time.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I'm not a frequent contributor on internals but I think a little something
is being missed here.
Passing callable instead of boolean (or something that converts to boolean)
is the altnerate way of making asserts fast without making them a language
construct (in other programming languages).
Showing by example. Forget about language construct assert and assuming
its simply a function.
Example 1: assert takes boolean
$func = function(){ /* stuff */ }
assert(func())
in dev and production environments, func() is evaluated before assert is
called.
Example 2: assert takes callable
$func = function(){ /* stuff */}
assert(func)
In dev environments, assert calls func, but in production environments,
assert returns immediately and func is never called.
My understanding is that adding language level constructs adds overhead to
the language as a whole. In my mind, assert taking callable should be an
ALTERNATIVE to assert as a language level construct.
Thanks and lemme know if I'm misunderstanding,
Will Bartlett
--
William Bartlett
College of Engineering | Cornell University '14
240-432-5189
Hi Dmitry,
but we can write:
$f = function() {return FALSE;};
assert($f());I'll use this form, if
assert()does not support direct closure call.
Direct call seems cleaner to me.assert(function() {
// Do complex assertion here.
};Users are used to this form because of JavaScript popularity.
It's a small difference, but I hope newassert()supports this :)Regards,
P.S. Thank you for the declare(pre/post_hook) comment. I'll look
into VM when I have time.--
Yasuo Ohgaki
yohgaki@ohgaki.net
Similar thing could be achieved with new
assert()w/o any overheads.https://wiki.php.net/rfc/expectations
assert('version_compare(PHP_VERSION, "5.5.0", ">=")', 'You need PHP 5.5.0
or later');
I'm confused, isn't this exactly how assert() already works? What needs
to change, for this example in particular?
Here it is running on several versions, giving a Warning by default:
http://3v4l.org/TrBJm
And here it is without the second parameter, which in itself requires
PHP 5.3: http://3v4l.org/mcQI6
It's slightly confusing that assertions issue a Warning even with
ASSERT_BAIL turned on, but with that turned on (which can be at the ini
level) you can see that it aborts the script as desired:
http://3v4l.org/QZLog
Regards,
--
Rowan Collins
[IMSoP]
On Tue, Feb 4, 2014 at 9:24 PM, Rowan Collins rowan.collins@gmail.comwrote:
Similar thing could be achieved with new
assert()w/o any overheads.https://wiki.php.net/rfc/expectations
assert('version_compare(PHP_VERSION, "5.5.0", ">=")', 'You need PHP 5.5.0
or later');I'm confused, isn't this exactly how
assert()already works? What needs to
change, for this example in particular?Here it is running on several versions, giving a Warning by default:
http://3v4l.org/TrBJm
And here it is without the second parameter, which in itself requires PHP
5.3: http://3v4l.org/mcQI6It's slightly confusing that assertions issue a Warning even with
ASSERT_BAILturned on, but with that turned on (which can be at the ini
level) you can see that it aborts the script as desired:
http://3v4l.org/QZLogRegards,
--
Rowan Collins
[IMSoP]--
with the current assert implementation the assert is a function, which
eval()-s the expression argument, but it will return early if asserts are
disabled(http://lxr.php.net/xref/PHP_5_5/ext/standard/assert.c#149)
with the proposed assert (https://wiki.php.net/rfc/expectations) the assert
will be changed into a language construct, which has the advantage that we
can use expressions instead of passing a string for evaluation without
additional cost, also executing that is cheaper than a function call, and
when the assertions are disabled they will be almost zero-cost.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
with the current assert implementation the assert is a function, which
eval()-s the expression argument, but it will return early if asserts
are disabled(http://lxr.php.net/xref/PHP_5_5/ext/standard/assert.c#149)
with the proposed assert (https://wiki.php.net/rfc/expectations) the
assert will be changed into a language construct, which has the
advantage that we can use expressions instead of passing a string for
evaluation without additional cost, also executing that is cheaper
than a function call, and when the assertions are disabled they will
be almost zero-cost.
Thanks for that. As posted elsewhere, I think the RFC could make that
clearer.
So the relevance to this discussion is that you could already do a
version check with an assert(), and the proposed version of assert()
would be as efficient as the proposed declare(); does that sound right?
--
Rowan Collins
[IMSoP]
On Tue, Feb 4, 2014 at 10:28 PM, Rowan Collins rowan.collins@gmail.comwrote:
with the current assert implementation the assert is a function, which
eval()-s the expression argument, but it will return early if asserts are
disabled(http://lxr.php.net/xref/PHP_5_5/ext/standard/assert.c#149)
with the proposed assert (https://wiki.php.net/rfc/expectations) the
assert will be changed into a language construct, which has the advantage
that we can use expressions instead of passing a string for evaluation
without additional cost, also executing that is cheaper than a function
call, and when the assertions are disabled they will be almost zero-cost.Thanks for that. As posted elsewhere, I think the RFC could make that
clearer.So the relevance to this discussion is that you could already do a version
check with anassert(), and the proposed version ofassert()would be as
efficient as the proposed declare(); does that sound right?
I would wait for Yasuo to answer, but that my understanding, yes.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi all,
with the current assert implementation the assert is a function, which
eval()-s the expression argument, but it will return early if asserts
are
disabled(http://lxr.php.net/xref/PHP_5_5/ext/standard/assert.c#149)
with the proposed assert (https://wiki.php.net/rfc/expectations) the
assert will be changed into a language construct, which has the
advantage
that we can use expressions instead of passing a string for evaluation
without additional cost, also executing that is cheaper than a function
call, and when the assertions are disabled they will be almost
zero-cost.Thanks for that. As posted elsewhere, I think the RFC could make that
clearer.So the relevance to this discussion is that you could already do a
version
check with anassert(), and the proposed version ofassert()would be as
efficient as the proposed declare(); does that sound right?I would wait for Yasuo to answer, but that my understanding, yes.
Yes. New assert() is as efficient as declare().
I cannot wait to use new assert()!
Regards,
P.S. I really would like to have 'callable' as the 1st parameter of new
assert().
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
Yes. New
assert()is as efficient as declare().
I cannot wait to use newassert()!
Yasuo
Please can you explain why you think this is so essential? The only place I can
think that I would use this I ALSO need to advise the users that there is a
problem. Adding 'assert' which apparently only has use while debugging just
seems wrong. Alright I add vd() and similar myself when debugging code rather
than using a 'debugger', but if I need to test something only at debug time then
I'll just add code and remove it when I have sorted the problem. If it is a
problem which will stop the code running, then it needs a proper response in the
workflow anyway.
ADOdb and smarty both have switches to enable debugging which can be switched on
as required at runtime and I can't see any reason they would switch to using
assert instead?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Yasuo Ohgaki wrote:
Yes. New
assert()is as efficient as declare().
I cannot wait to use newassert()!Yasuo
Please can you explain why you think this is so essential? The only place I
can think that I would use this I ALSO need to advise the users that there
is a problem. Adding 'assert' which apparently only has use while debugging
just seems wrong. Alright I add vd() and similar myself when debugging code
rather than using a 'debugger', but if I need to test something only at
debug time then I'll just add code and remove it when I have sorted the
problem. If it is a problem which will stop the code running, then it needs
a proper response in the workflow anyway.ADOdb and smarty both have switches to enable debugging which can be
switched on as required at runtime and I can't see any reason they would
switch to using assert instead?
Let me rephrase that in another way.
It is no rocket science to correctly setup a production server.
Disable display errors, eanble log, create error pages (404, etc.).
Anyone not being able to understand or able to actually do it has
nothing to do anywhere closed to a production server.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
Yasuo Ohgaki wrote:
Yes. New
assert()is as efficient as declare().
I cannot wait to use newassert()!Yasuo
Please can you explain why you think this is so essential? The only place I
can think that I would use this I ALSO need to advise the users that there
is a problem. Adding 'assert' which apparently only has use while debugging
just seems wrong. Alright I add vd() and similar myself when debugging code
rather than using a 'debugger', but if I need to test something only at
debug time then I'll just add code and remove it when I have sorted the
problem. If it is a problem which will stop the code running, then it needs
a proper response in the workflow anyway.ADOdb and smarty both have switches to enable debugging which can be
switched on as required at runtime and I can't see any reason they would
switch to using assert instead?
Let me rephrase that in another way.It is no rocket science to correctly setup a production server.
Disable display errors, eanble log, create error pages (404, etc.).
Anyone not being able to understand or able to actually do it has
nothing to do anywhere closed to a production server.
Pierre - now you have lost me totally ...
What does this have to do with 'assert' ?
I'm quite happy to put my hands up and say "I don't understand why it's needed"
If you look at the bulk of PHP users, they are using PHP via a hosting service,
who set up the 'production server' for them. When they install an 'application',
it's install section takes care of configuration. Then the ISP changes PHP
version and they get a white screen ... help ...
At this point what PHP needs to supply as a minimum is just a 'php has crashed
please check log', but ideally we should be able to direct these 'simple' users
back to their installation section if that can handle the problem. 95% of users
would probably not understand what the difference between a production and
develop server is? Telling them they have no place using PHP is not acceptable?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
If you look at the bulk of PHP users, they are using PHP via a hosting
service, who set up the 'production server' for them. When they install an
'application', it's install section takes care of configuration. Then the
ISP changes PHP version and they get a white screen ... help ...At this point what PHP needs to supply as a minimum is just a 'php has
crashed please check log', but ideally we should be able to direct these
'simple' users back to their installation section if that can handle the
problem. 95% of users would probably not understand what the difference
between a production and develop server is? Telling them they have no place
using PHP is not acceptable?
I think your comment is valuable.
Under production environment, web apps should not display any internal data
including PHP errors.
However, it may be a good idea to have option for administrators to display
some messages.
Perhaps, INI like
fatal_error_message = "Program had fatal error. Please consult XXXXXX"
might be useful for ISPs admins and users.
Regards,
Yasuo Ohgaki
yohgaki@ohgaki.net
hi,
Hi Lester,
If you look at the bulk of PHP users, they are using PHP via a hosting
service, who set up the 'production server' for them. When they install an
'application', it's install section takes care of configuration. Then the
ISP changes PHP version and they get a white screen ... help ...At this point what PHP needs to supply as a minimum is just a 'php has
crashed please check log', but ideally we should be able to direct these
'simple' users back to their installation section if that can handle the
problem. 95% of users would probably not understand what the difference
between a production and develop server is? Telling them they have no place
using PHP is not acceptable?I think your comment is valuable.
Under production environment, web apps should not display any internal data
including PHP errors.
However, it may be a good idea to have option for administrators to display
some messages.
Perhaps, INI likefatal_error_message = "Program had fatal error. Please consult XXXXXX"
might be useful for ISPs admins and users.
ISPs admins (or any admins) can read logs, and will read logs. They do
check customers error logs to prevent flaws, issues, excessive
resource usages, etc. Panels and other user friendly systems provide
log viewers with alerts.
But the key point remains the same, no error should be displayed in
production (whatever hosting is used), this is well documented since
years. I have some hard time to understand why we keep having to
explain why. If the documentation needs improvements, then let try to
fix it. But adding yet another option to finally do something that we
try to prevent since years does not sound very appealing to me.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
But the key point remains the same, no error should be displayed in
production (whatever hosting is used), this is well documented since
years. I have some hard time to understand why we keep having to
explain why. If the documentation needs improvements, then let try to
fix it. But adding yet another option to finally do something that we
try to prevent since years does not sound very appealing to me.
I get it that all user gets is a white screen because that is what has been
documented to returned. In the past we at least got something, but in these
modern times IS a blank screen really an acceptable return? If it was just
returning messy displays it would at least be something and we can then build on
that to get things working properly.
A number of my customers have come to me because they got no help from their
ISP's and other ISP's switched back to older versions of PHP because too many
sites simply broke. They don't have enough staff to fix PHP code and it's not
their job? One of the best ways of getting the PHP5.2 sites updated is providing
a default setup that minimizes the occurrence of a blank page. As Yasuo says
'even just a warning page'. With a blank page would a simple user even know that
PHP has anything to do with why it's blank?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
But the key point remains the same, no error should be displayed in
production (whatever hosting is used), this is well documented since
years. I have some hard time to understand why we keep having to
explain why. If the documentation needs improvements, then let try to
fix it. But adding yet another option to finally do something that we
try to prevent since years does not sound very appealing to me.I get it that all user gets is a white screen because that is what has
been documented to returned. In the past we at least got something, but in
these modern times IS a blank screen really an acceptable return? If it was
just returning messy displays it would at least be something and we can
then build on that to get things working properly.A number of my customers have come to me because they got no help from
their ISP's and other ISP's switched back to older versions of PHP because
too many sites simply broke. They don't have enough staff to fix PHP code
and it's not their job? One of the best ways of getting the PHP5.2 sites
updated is providing a default setup that minimizes the occurrence of a
blank page. As Yasuo says 'even just a warning page'. With a blank page
would a simple user even know that PHP has anything to do with why it's
blank?
It is not a php problem per se. Php cannot do anything after a fatal error
or a crash.
It takes 5 mins to any admin (7 for non Admin) to setup a default error
page, in any webserver. And it does exactly what you suggest.
Cheers,
Pierre
Pierre Joye wrote:
With a blank page would a simple user even know that PHP has anything to do with
why it's blank?It is not a php problem per se. Php cannot do anything after a fatal error or a
crash.
So how do we protect PHP from crashing in such a way that it can actually
display an alternate page to the 'white screen of death'?
It takes 5 mins to any admin (7 for non Admin) to setup a default error page, in
any webserver. And it does exactly what you suggest.
So why are there so many reports of 'white screen of death' if it is easy to
provide something more useful? Even the big frameworks seem to have a problem
with this.
I do think this is an important area in order to bring forward the majority of
the current user base ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
With a blank page would a simple user even know that PHP has anything to
do with
why it's blank?It is not a php problem per se. Php cannot do anything after a fatal
error or a
crash.So how do we protect PHP from crashing in such a way that it can actually
display an alternate page to the 'white screen of death'?It takes 5 mins to any admin (7 for non Admin) to setup a default error
page, in
any webserver. And it does exactly what you suggest.So why are there so many reports of 'white screen of death' if it is easy
to provide something more useful?
One of top reasons? Display error on, a warning/notice/whatever is
displayed, broke the html/page, showing a "white" page. Which is indeed not
empty.
Even the big frameworks seem to have a problem with this.
I do not know any big framework having issues with that.
Hi Lester,
Yasuo Ohgaki wrote:
Yes. New
assert()is as efficient as declare().
I cannot wait to use newassert()!Yasuo
Please can you explain why you think this is so essential? The only place
I can think that I would use this I ALSO need to advise the users that
there is a problem. Adding 'assert' which apparently only has use while
debugging just seems wrong. Alright I add vd() and similar myself when
debugging code rather than using a 'debugger', but if I need to test
something only at debug time then I'll just add code and remove it when I
have sorted the problem. If it is a problem which will stop the code
running, then it needs a proper response in the workflow anyway.
Since I'm a developer, I do not pay much attention once code hits
production. (I do care errors a lot, though. I catch all errors/exceptions
as a sign of fatal errors) Therefore, assert() is enough for me to alert
users(developers) to notify something wrong during development.
In contract, I think you pay much attention to production environment. I
think it is very important for us (PHP internal developers) also. I guess
you're dealing with a lot of end users and getting annoyed by PHP changes.
Checking requirements at compile time would be valuable for you as you may
configure PHP to display completely broken scripts for the environment.
(i.e. Display compile error)
For this use, declare() is the best solution. We might be better to think
again for your use.
ADOdb and smarty both have switches to enable debugging which can be
switched on as required at runtime and I can't see any reason they would
switch to using assert instead?
Assertion can be used to development time only checks so that programmers
notice silly mistakes, passing invalid arguments for function, range check,
type check, format check, pre/post condition check, etc. Even for ADOdb or
Smarty developers, they have conditions that should be checked only when
they are writing new code.
I like DbC in D and other languages. For example, D supports "in" as
precondition check, and "out" as post condition check.
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
With contract programming, caller has a responsibility to pass arguments
that meets precondition contract and callee has responsibility returns a
result that meets post condition contract. If whole program is made this
way, callee does not have to check pre/post condition at all as long as
input for program is validated
strictly. With contract programming, lower level functions does not have to
check arguments under production environment at all, thus program runs much
faster than traditional design yet it achieves robustness. (in theory.
We're better to leave some checks for fatal error especially for security
related matter)
Assertion that does not have run time overheads at all is very cool thing
for PHP developers to write robust and fast applications, especially for
developers who prefer micro frameworks. (Missing pace for PHP is pre/post
condition check, but it's much better than before and it can work round.
Comprehensive frameworks have contract via annotation, etc at user land.)
I agree that assert() may not help you much from your users asking "I got
blank screen!", but it helps developers a lot. It also may help you if your
user can change INI setting to see what's wrong.
Does this answer your question?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
Hi Lester,
On Wed, Feb 5, 2014 at 7:03 PM, Lester Caine <lester@lsces.co.uk
mailto:lester@lsces.co.uk> wrote:Yasuo Ohgaki wrote: Yes. New `assert()` is as efficient as declare(). I cannot wait to use new `assert()`! Yasuo Please can you explain why you think this is so essential? The only place I can think that I would use this I ALSO need to advise the users that there is a problem. Adding 'assert' which apparently only has use while debugging just seems wrong. Alright I add vd() and similar myself when debugging code rather than using a 'debugger', but if I need to test something only at debug time then I'll just add code and remove it when I have sorted the problem. If it is a problem which will stop the code running, then it needs a proper response in the workflow anyway.Since I'm a developer, I do not pay much attention once code hits production. (I
do care errors a lot, though. I catch all errors/exceptions as a sign of fatal
errors) Therefore,assert()is enough for me to alert users(developers) to
notify something wrong during development.In contract, I think you pay much attention to production environment. I think
it is very important for us (PHP internal developers) also. I guess you're
dealing with a lot of end users and getting annoyed by PHP changes. Checking
requirements at compile time would be valuable for you as you may configure PHP
to display completely broken scripts for the environment. (i.e. Display compile
error)For this use, declare() is the best solution. We might be better to think again
for your use.ADOdb and smarty both have switches to enable debugging which can be switched on as required at runtime and I can't see any reason they would switch to using assert instead?Assertion can be used to development time only checks so that programmers notice
silly mistakes, passing invalid arguments for function, range check, type check,
format check, pre/post condition check, etc. Even for ADOdb or Smarty
developers, they have conditions that should be checked only when they are
writing new code.I like DbC in D and other languages. For example, D supports "in" as
precondition check, and "out" as post condition check.long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}With contract programming, caller has a responsibility to pass arguments that
meets precondition contract and callee has responsibility returns a result that
meets post condition contract. If whole program is made this way, callee does
not have to check pre/post condition at all as long as input for program is
validated
strictly. With contract programming, lower level functions does not have to
check arguments under production environment at all, thus program runs much
faster than traditional design yet it achieves robustness. (in theory. We're
better to leave some checks for fatal error especially for security related matter)Assertion that does not have run time overheads at all is very cool thing for
PHP developers to write robust and fast applications, especially for developers
who prefer micro frameworks. (Missing pace for PHP is pre/post condition check,
but it's much better than before and it can work round. Comprehensive frameworks
have contract via annotation, etc at user land.)I agree that
assert()may not help you much from your users asking "I got blank
screen!", but it helps developers a lot. It also may help you if your user can
change INI setting to see what's wrong.Does this answer your question?
Yes and no ... Thank you very much for taking the time!
It does explain nicely what is being talked about, and I can now understand
where you are coming from. I have some 20 years of programming experience
predating using PHP, and switched to PHP mainly because it did NOT have the same
straight jacket that c/c++ imposes. My customers are simply using PHP
applications to do a job, and they have no interest in many of the things
currently being pushed forward as 'essential' here. I think reading the above
that you will understand that? They just want their applications to continue to
work ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.phpSomething like
<?php
declare(php_version>='5.6.0');
// or PHP_VERSION_ID? using = as minimum as it could be a little faster
// and no change in declare() syntax.
declare(php_version=50600);
While I like it from a formality stand-point, I have to agree with
Stas. The is entirely doable as PHP code right now. Include time IS
execute time. And if you're concerned with a single integer compare
in your perf analysis, you're probably worried about the wrong thing.
-Sara
Hi Sara,
I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.phpSomething like
<?php
declare(php_version>='5.6.0');
// or PHP_VERSION_ID? using = as minimum as it could be a little faster
// and no change in declare() syntax.
declare(php_version=50600);While I like it from a formality stand-point, I have to agree with
Stas. The is entirely doable as PHP code right now. Include time IS
execute time. And if you're concerned with a single integer compare
in your perf analysis, you're probably worried about the wrong thing.
I may be worried to much, but I don't like run time environment checks
which evaluated over and over. There are many codes that checks PHP
version, loaded extension, library version, etc to make sure code works as
it should be. Perhaps, more generic form might be better
declare('requirements') {
if (version_compare(PHP_VERSION, '5.6.0', '<')) {
echo 'You need PHP 5.6.0 or later';
return FALSE;
}
if (!extension_loaded('foo')) {
echo 'You need foo extension';
return FALSE;
}
// and so on
return TRUE;
}
for example.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I may be worried to much, but I don't like run time environment checks
which evaluated over and over. There are many codes that checks PHP
version, loaded extension, library version, etc to make sure code works as
it should be. Perhaps, more generic form might be betterdeclare('requirements') {
if (version_compare(PHP_VERSION, '5.6.0', '<')) {
echo 'You need PHP 5.6.0 or later';
return FALSE;
}
if (!extension_loaded('foo')) {
echo 'You need foo extension';
return FALSE;
}
// and so on
return TRUE;
}
That still has to run each time the file is included.
johannes
Hi Johannes,
On Tue, Feb 4, 2014 at 7:09 AM, Johannes Schlüter johannes@schlueters.dewrote:
I may be worried to much, but I don't like run time environment checks
which evaluated over and over. There are many codes that checks PHP
version, loaded extension, library version, etc to make sure code works
as
it should be. Perhaps, more generic form might be betterdeclare('requirements') {
if (version_compare(PHP_VERSION, '5.6.0', '<')) {
echo 'You need PHP 5.6.0 or later';
return FALSE;
}
if (!extension_loaded('foo')) {
echo 'You need foo extension';
return FALSE;
}
// and so on
return TRUE;
}That still has to run each time the file is included.
Zend engine does not have to store byte codes of declare block as it is
compiler directive. It would be beneficial with byte code cache.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
2014.02.03. 7:59, "Yasuo Ohgaki" yohgaki@ohgaki.net ezt írta:
Hi all,
I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.phpSomething like
<?php
declare(php_version>='5.6.0');
// or PHP_VERSION_ID? using = as minimum as it could be a little faster
// and no change in declare() syntax.
declare(php_version=50600);If version mismatches, raise compile error and exit. Something like
Compile error: PHP 5.6.0 or later is required to compile script. Your PHP
version is 5.x.x.The same thing can be done by
version_compare()and die(), but it does not
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when it is
included, not when it is executed. I wouldn't writeversion_compare()and
die() for libraries, but I may use it if it's a declare(). If this is
adopted widely, it may help transition to higher versions hoping users to
consider compile error more seriously.Issue would be current behavior for unsupported declaration.
$ php -r "declare(php_version=050600);"
Warning: Unsupported declare 'php_version' in Command line code on line 1
It does not raise E_ERROR, but E_WARNING.Just an idea.
Any comments?--
Yasuo Ohgaki
yohgaki@ohgaki.net
I don't like the idea.
First I don't think that it is a good practice for a library to directly
terminate the execution of the application, and because this would be a
compile-time check, I don't think we could provide any sane way of allowing
the execution of the code.
I also think that the performance gain is too small to the average/small
users (compared to the usual low-hanging fruits like using an opcode cache,
proper autoloading, etc.) while the big users would be doing the checks
installation-time anyways, so they wouldn't use it.
For general purpose applications (like drupal/wordpress/etc.) it wouldn't
be useful either, because they want nice and descriptive error screens
instead of php fatal errors which would most of the time just result in a
blank screen and some lines in the error log.
The only target audience would be the specific group of library developers
who think that the execution of their lib is more important than the app
which calls them, and for those people we already have version_compare()
and exit.
Ps: sent from my phone, sorry for the typos.
Ferenc Kovacs wrote:
For general purpose applications (like drupal/wordpress/etc.) it wouldn't
be useful either, because they want nice and descriptive error screens
instead of php fatal errors which would most of the time just result in a
blank screen and some lines in the error log.
This is perhaps one of the areas that would benefit from some improvement in a
PHP6 roadmap. It IS all too easy to get a blank screen already without adding
more? Invariably when an ISP upgrades their PHP service a number of their client
sites simply give a white screen, and in many cases the users have no idea where
to go next? More verbose responses actually on screen would be a little more
constructive. Performance improvements are all very well, and do have a place,
but a white screen is no use at all? Certainly it's a not uncommon result these
days when upgrading PHP versions ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Ferenc Kovacs wrote:
For general purpose applications (like drupal/wordpress/etc.) it wouldn't
be useful either, because they want nice and descriptive error screens
instead of php fatal errors which would most of the time just result in a
blank screen and some lines in the error log.This is perhaps one of the areas that would benefit from some improvement in a PHP6 roadmap. It IS all too easy to get a blank screen already without adding more? Invariably when an ISP upgrades their PHP service a number of their client sites simply give a white screen, and in many cases the users have no idea where to go next? More verbose responses actually on screen would be a little more constructive. Performance improvements are all very well, and do have a place, but a white screen is no use at all? Certainly it's a not uncommon result these days when upgrading PHP versions ...
well, idea is that production web-sites should never report details of their inner workings (including errors) on screen.
error-report is in the error-log.
but nice useful errors are a benefit of their own, so I hope that PHP6 will have
https://wiki.php.net/rfc/engine_exceptions
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
Hi all,
I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.php
I have concluded that these check should be done by new assert()
https://wiki.php.net/rfc/expectations
I think of another idea for declare(). Current declare() has 'tick'.
How about have hooks 'pre_hook' and 'post_hook'?
It works like tick. Tick executes registered function/code by execution
cycle.
'pre_hook' and 'post_hook' executes registered function/code before
function call
and after function call. Something like
declare(pre_hook=TYPE) { some_useful_code }
declare(post_hook=TYPE) { some_useful_code }
Where TYPE is 0=none, 1=user, 2=internal, 3=both.
'none' is for to use hook inside function body.
These hooks are executed like
function foo() {
// pre_hook hook here
some useful code
// post_hook hook here (executed for all 'return')
}
This is useful for user land PHP debugger/profiler as well as pre/post
condition checks. We have dbg, but it's nice to have hook in user
land for simple debugging and profiling also. It may be convenient if
hooked functions/methods can be specified, but it might be headache
with namespace. Simply hooking all calls might be simpler as it does
not have to be fast.
Or declare() may be used inside functions.
function foo() {
declare(pre_hook=0) { some useful code }
declare(post_hook=0) { some useful code }
body
}
There are many way for hook design.
Just an another idea for declare().
It would be useful, but it lacks elegance...
Since declare() is compiler directive, INI is needed for enabling/disabling
when user want hook for all files.
Any comments for this feature?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
This feature may be too expensive, because it would slowdown every function
call even with hooks disabled (to check if they are enabled).
It's also going to complicate execution because separate peaces of code are
going to use the same variables. So VM will have to construct and use
symbol table (hash table) instead of CV (directly indexed variable slots).
Thanks. Dmitry.
Hi all,
I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.phpI have concluded that these check should be done by new
assert()https://wiki.php.net/rfc/expectations
I think of another idea for declare(). Current declare() has 'tick'.
How about have hooks 'pre_hook' and 'post_hook'?It works like tick. Tick executes registered function/code by execution
cycle.
'pre_hook' and 'post_hook' executes registered function/code before
function call
and after function call. Something likedeclare(pre_hook=TYPE) { some_useful_code }
declare(post_hook=TYPE) { some_useful_code }Where TYPE is 0=none, 1=user, 2=internal, 3=both.
'none' is for to use hook inside function body.These hooks are executed like
function foo() {
// pre_hook hook here
some useful code
// post_hook hook here (executed for all 'return')
}This is useful for user land PHP debugger/profiler as well as pre/post
condition checks. We have dbg, but it's nice to have hook in user
land for simple debugging and profiling also. It may be convenient if
hooked functions/methods can be specified, but it might be headache
with namespace. Simply hooking all calls might be simpler as it does
not have to be fast.Or declare() may be used inside functions.
function foo() {
declare(pre_hook=0) { some useful code }
declare(post_hook=0) { some useful code }
body
}There are many way for hook design.
Just an another idea for declare().
It would be useful, but it lacks elegance...
Since declare() is compiler directive, INI is needed for enabling/disabling
when user want hook for all files.Any comments for this feature?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net