Hi developers,
Trying to resolve the bug #75950 (that after long hours I found that I
couldn't reproduce), I observed that if zend.assertions >= 0
the
generated code inside assert()
was indeed executed even if assert.active = off
. Naturally the function arguments were evaluated before entering
into the assert()
function.
https://bugs.php.net/bug.php?id=75950
The point is that will be possible to fully disable assertions setting
assert.active = false
after initialization if we turn assert
into a
statement. This can mantain fully backward compatibility. Calling
assert_options(ASSERT_ACTIVE, true)
or false
after initialization would
fully enable or disable the functionality. It seems the most sensible thing
to do.
By the way assert
in Java and Python is an statement, and in C it isn't a
function.
So my question is what is the purpose of mantaining assert()
a function,
there are any drawbacks of fully disabling it when zend.assertions >= 0
?
PS: Strange that nobody cared in recent emails about the proposal to a
small increase of the testing coverage by doubling the testing time
duration, was somewhat interesting.
--
Atenciosamente,
Pedro Lacerda
Hi developers,
Trying to resolve the bug #75950 (that after long hours I found that I
couldn't reproduce), I observed that ifzend.assertions >= 0
the
generated code insideassert()
was indeed executed even ifassert.active = off
. Naturally the function arguments were evaluated before entering
into theassert()
function.https://bugs.php.net/bug.php?id=75950
The point is that will be possible to fully disable assertions setting
assert.active = false
after initialization if we turnassert
into a
statement. This can mantain fully backward compatibility. Calling
assert_options(ASSERT_ACTIVE, true)
orfalse
after initialization would
fully enable or disable the functionality. It seems the most sensible thing
to do.By the way
assert
in Java and Python is an statement, and in C it isn't a
function.So my question is what is the purpose of mantaining
assert()
a function,
there are any drawbacks of fully disabling it whenzend.assertions >= 0
?PS: Strange that nobody cared in recent emails about the proposal to a
small increase of the testing coverage by doubling the testing time
duration, was somewhat interesting.
Assert.active is the legacy PHP 5 control. Don’t use it.
zend.assertions -1 has the behavior you want. 0 emulates PHP 5 and
earlier’s broken implementation of assert. If you don’t have legacy
software to babysit, don’t use it.
The same beharviour, but assert
as statement also uses 1 character less.
Em 14 de fev de 2018 10:13 AM, "Michael Morris" tendoaki@gmail.com
escreveu:
Hi developers,
Trying to resolve the bug #75950 (that after long hours I found that I
couldn't reproduce), I observed that ifzend.assertions >= 0
the
generated code insideassert()
was indeed executed even ifassert.active = off
. Naturally the function arguments were evaluated before entering
into theassert()
function.https://bugs.php.net/bug.php?id=75950
The point is that will be possible to fully disable assertions setting
assert.active = false
after initialization if we turnassert
into a
statement. This can mantain fully backward compatibility. Calling
assert_options(ASSERT_ACTIVE, true)
orfalse
after initialization would
fully enable or disable the functionality. It seems the most sensible thing
to do.By the way
assert
in Java and Python is an statement, and in C it isn't a
function.So my question is what is the purpose of mantaining
assert()
a function,
there are any drawbacks of fully disabling it whenzend.assertions >= 0
?PS: Strange that nobody cared in recent emails about the proposal to a
small increase of the testing coverage by doubling the testing time
duration, was somewhat interesting.
Assert.active is the legacy PHP 5 control. Don’t use it.
zend.assertions -1 has the behavior you want. 0 emulates PHP 5 and
earlier’s broken implementation of assert. If you don’t have legacy
software to babysit, don’t use it.
My earlier reply was through my phone. I've since read the bug report and
saw your note where you couldn't reproduce it.
Assert is a statement in PHP 7. Try this code
function foo() {
debug_print_backtrace()
;
return true;
}
assert(foo());
In PHP 7 only foo() will be in the backtrace. In PHP 5 assert will be
listed as well.
What you are proposing has already been done. It's also why
zend.assertions has three settings: 1: on, -1: off, 0: emulate PHP 5.
Unless you have code on your hands that is breaking when the -1 setting is
used, the 0 setting should never be used.
The same beharviour, but
assert
as statement also uses 1 character less.Em 14 de fev de 2018 10:13 AM, "Michael Morris" tendoaki@gmail.com
escreveu:Hi developers,
Trying to resolve the bug #75950 (that after long hours I found that I
couldn't reproduce), I observed that ifzend.assertions >= 0
the
generated code insideassert()
was indeed executed even if
assert.active = off
. Naturally the function arguments were evaluated before entering
into theassert()
function.https://bugs.php.net/bug.php?id=75950
The point is that will be possible to fully disable assertions setting
assert.active = false
after initialization if we turnassert
into a
statement. This can mantain fully backward compatibility. Calling
assert_options(ASSERT_ACTIVE, true)
orfalse
after initialization
would
fully enable or disable the functionality. It seems the most sensible
thing
to do.By the way
assert
in Java and Python is an statement, and in C it
isn't a
function.So my question is what is the purpose of mantaining
assert()
a
function,
there are any drawbacks of fully disabling it whenzend.assertions >= 0
?PS: Strange that nobody cared in recent emails about the proposal to a
small increase of the testing coverage by doubling the testing time
duration, was somewhat interesting.Assert.active is the legacy PHP 5 control. Don’t use it.
zend.assertions -1 has the behavior you want. 0 emulates PHP 5 and
earlier’s broken implementation of assert. If you don’t have legacy
software to babysit, don’t use it.
In PHP 7 only foo() will be in the backtrace. In PHP 5 assert will be
listed as well.What you are proposing has already been done. It's also why
zend.assertions has three settings: 1: on, -1: off, 0: emulate PHP 5.
Unless you have code on your hands that is breaking when the -1 setting is
used, the 0 setting should never be used.
I don't think that's true. 0 can be used to dynamically switch
assertions on and off, which can be useful in some applications.
Regards, Niklas
2018-02-14 12:40 GMT-03:00 Michael Morris tendoaki@gmail.com:
Assert is a statement in PHP 7. Try this code
function foo() {
debug_print_backtrace()
;
return true;
}assert(foo());
In PHP 7 only foo() will be in the backtrace. In PHP 5 assert will be
listed as well.
I saw all that PHP_FUNCTION
and ZEND_PARSE_PARAMETERS
so thought that
was just a regular exposed function with compilation toggled by setting.
Anyway doing it directly in the lexer would avoid the argument parsing step
(and turning parentesis optional).
2018-02-14 13:29 GMT-03:00 Niklas Keller me@kelunik.com:
I don't think that's true. 0 can be used to dynamically switch
assertions on and off, which can be useful in some applications.
This can be useful for testing frameworks which does contract programming
by assertions but only in development.
Atenciosamente,
Pedro