In regards to E_STRICT and PHP5

20 years ago by boots — view source — reply

unread

I was hoping that in the future, E_STRICT wasn't expanded and was
perhaps even taken back a step. I understand the reason for it: code
correctness. Yet if PHP5 is (rightly) considered a runtime engine then
its job should be to evaluate and execute code and in the case of
failure, explain why it could not do so. In other words, if a code
segment is valid, then the runtime should just do its job and run that
code. Code correctness is the job for offline tools like lint. Yes, PHP
is a dynamic language so things like E_NOTICE are often required to be
triggered by the runtime. Yet the only place keywords can be generated
dynamically is through an eval -- and I suggest that getting deprecated
warnings at that point is not very enlightening. There is another
difference between an E_NOTICE and a deprecated warning: the first can
lead to (or mask) programming errors, the second can not. Its almost as
if another error flag (not error level) was needed, something like
E_DEPRECATED. The real question is, should the runtime be concerned
about that or should that be something that the toolchain handles? I
would rather the latter.

If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think it should be removed as a
keyword. If it is acceptable, the engine shouldn't complain about it.
(of course, I think it is acceptable.)

Very best regards and thanks.

20 years ago by Zeev Suraski — view source — reply

unread

Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.

I think it can help, and I don't see how it can hurt given the fact it's
not on unless you want it to.

Zeev

At 19:30 16/06/2005, boots wrote:

I was hoping that in the future, E_STRICT wasn't expanded and was
perhaps even taken back a step. I understand the reason for it: code
correctness. Yet if PHP5 is (rightly) considered a runtime engine then
its job should be to evaluate and execute code and in the case of
failure, explain why it could not do so. In other words, if a code
segment is valid, then the runtime should just do its job and run that
code. Code correctness is the job for offline tools like lint. Yes, PHP
is a dynamic language so things like E_NOTICE are often required to be
triggered by the runtime. Yet the only place keywords can be generated
dynamically is through an eval -- and I suggest that getting deprecated
warnings at that point is not very enlightening. There is another
difference between an E_NOTICE and a deprecated warning: the first can
lead to (or mask) programming errors, the second can not. Its almost as
if another error flag (not error level) was needed, something like
E_DEPRECATED. The real question is, should the runtime be concerned
about that or should that be something that the toolchain handles? I
would rather the latter.

If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think it should be removed as a
keyword. If it is acceptable, the engine shouldn't complain about it.
(of course, I think it is acceptable.)

Very best regards and thanks.

20 years ago by Dan Scott — view source — reply

unread

Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.

Well, that depends on your definition of "default";
php.ini-recommended in HEAD shows:

; - Show all errors, including coding standards warnings
;
error_reporting = E_ALL | E_STRICT

-- so the user who does 'cp php.ini-recommended /etc/php.ini' is, in
fact, getting E_STRICT by default with the recommended configuration.

Perhaps E_ALL should be the default in php.ini-recommended, with E_ALL
| E_STRICT a documented (but commented) option.

Dan

20 years ago by Sara Golemon — view source — reply

unread

If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think it should be removed as a
keyword. If it is acceptable, the engine shouldn't complain about it.
(of course, I think it is acceptable.)

Answer: No, it's not acceptable. But expecting everyone out there using PHP
to update their code (which they probably didn't write themselves anyway) is
even more unacceptable. Solution: Throw no warnings in the default error
reporting level, but provide a hook for script developers to find the code
that needs changing.

If anything, E_STRICT needs expanding. For example, zend_function_entry
should have a flag to indicate deprecation. When a deprecated method is
called: zend_error(E_STRICT, "Call to deprecated function %s()", fname);

-Sara

20 years ago by Zeev Suraski — view source — reply

unread

At 19:57 16/06/2005, Sara Golemon wrote:

If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think it should be removed as a
keyword. If it is acceptable, the engine shouldn't complain about it.
(of course, I think it is acceptable.)

Answer: No, it's not acceptable. But expecting everyone out there using PHP
to update their code (which they probably didn't write themselves anyway) is
even more unacceptable. Solution: Throw no warnings in the default error
reporting level, but provide a hook for script developers to find the code
that needs changing.

If anything, E_STRICT needs expanding. For example, zend_function_entry
should have a flag to indicate deprecation. When a deprecated method is
called: zend_error(E_STRICT, "Call to deprecated function %s()", fname);

I think that's a good idea.

Zeev

20 years ago by Andi Gutmans — view source — reply

unread

You missed the point of E_STRICT. I introduced it as an E_PEDANTIC. That
was the whole idea. To be pedantic about code that works, not to warn about
code that doesn't work (which is for higher warning levels)

At 09:30 AM 6/16/2005 -0700, boots wrote:

I was hoping that in the future, E_STRICT wasn't expanded and was
perhaps even taken back a step. I understand the reason for it: code
correctness. Yet if PHP5 is (rightly) considered a runtime engine then
its job should be to evaluate and execute code and in the case of
failure, explain why it could not do so. In other words, if a code
segment is valid, then the runtime should just do its job and run that
code. Code correctness is the job for offline tools like lint. Yes, PHP
is a dynamic language so things like E_NOTICE are often required to be
triggered by the runtime. Yet the only place keywords can be generated
dynamically is through an eval -- and I suggest that getting deprecated
warnings at that point is not very enlightening. There is another
difference between an E_NOTICE and a deprecated warning: the first can
lead to (or mask) programming errors, the second can not. Its almost as
if another error flag (not error level) was needed, something like
E_DEPRECATED. The real question is, should the runtime be concerned
about that or should that be something that the toolchain handles? I
would rather the latter.

If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think it should be removed as a
keyword. If it is acceptable, the engine shouldn't complain about it.
(of course, I think it is acceptable.)

Very best regards and thanks.

20 years ago by Dan Scott — view source — reply

unread

At 20:39 16/06/2005, Dan Scott wrote:

Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.

Well, that depends on your definition of "default";

I meant what PHP comes with built-in / php.ini-dist.

php.ini-recommended in HEAD shows:

; - Show all errors, including coding standards warnings
;
error_reporting = E_ALL | E_STRICT

-- so the user who does 'cp php.ini-recommended /etc/php.ini' is, in
fact, getting E_STRICT by default with the recommended configuration.

Perhaps E_ALL should be the default in php.ini-recommended, with E_ALL
| E_STRICT a documented (but commented) option.

Maybe we should be a bit more clear with what we say there.

Zeev

To be fair, INSTALL does say:

If you instead choose php.ini-recommended, be certain to read the list
of changes within, as they affect how PHP behaves.

but php.ini-recommended, in the list of changes vs. php.ini-dist, says:

; - error_reporting = E_ALL [Code Cleanliness, Security(?)]
; By default, PHP surpresses errors of type E_NOTICE. These error messages
; are emitted for non-critical errors, but that could be a symptom
of a bigger
; problem. Most notably, this will cause error messages about the use
; of uninitialized variables to be displayed.

-- so yes, we need to update this section to note the addition of
E_STRICT and the deprecation warnings to the list.

Suggested patch:

--- php.ini-recommended 2005-06-01 23:27:16.000000000 -0400
+++ php.ini-new 2005-06-16 14:09:01.803325720 -0400
@@ -111,11 +111,12 @@
; - variables_order = "GPCS" [Performance]
; The environment variables are not hashed into the $_ENV. To access
; environment variables, you can use getenv() instead.
-; - error_reporting = E_ALL [Code Cleanliness, Security(?)]
-; By default, PHP surpresses errors of type E_NOTICE. These error messages
+; - error_reporting = E_ALL | E_STRICT [Code Cleanliness, Security(?)]
+; By default, PHP suppresses errors of type E_NOTICE. These error messages
; are emitted for non-critical errors, but that could be a
symptom of a bigger
; problem. Most notably, this will cause error messages about the use
-; of uninitialized variables to be displayed.
+; of uninitialized variables to be displayed. Adding E_STRICT will cause
+; deprecation warnings for functions like dl() to be displayed.
; - allow_call_time_pass_reference = Off [Code cleanliness]
; It's not possible to decide to force a variable to be passed by reference
; when calling a function. The PHP 4 style to do this is by making the

Dan