Folks,
http://bugs.php.net/52563 suggests adding an E_NONE constant (set to 0) to
go with the various other E_* constants we have. I've hacked up a quick
patch against trunk (attached to the report) that would add that, but don't
have Zend karma to add it, so I'll open it up to the floor: (a) should we
have it, and (b) if so, can someone please commit it?
Johannes has pointed out on IRC that E_NONE does already exist in some
projects, so that's an argument against it.
Kalle also suggested another constant within that request to provide a
symbolic version of error_reporting = -1, so there's a second patch in that
report to add an E_EVERYTHING constant which acts as E_ALL once did: it
turns on all error reporting.
I'm not terribly attached to either the names or, indeed, the request in
general, but it'd be nice to get this one closed one way or t'other.
Adam
hi,
http://bugs.php.net/52563 suggests adding an E_NONE constant (set to 0) to
go with the various other E_* constants we have. I've hacked up a quick
patch against trunk (attached to the report) that would add that, but don't
have Zend karma to add it, so I'll open it up to the floor: (a) should we
have it, and (b) if so, can someone please commit it?Johannes has pointed out on IRC that E_NONE does already exist in some
projects, so that's an argument against it.
I don't see it as an argument against as the fix is rather easy:
if (!defined('E_NONE')) {
...
But it should not be added in a minor release.
Kalle also suggested another constant within that request to provide a
symbolic version of error_reporting = -1, so there's a second patch in that
report to add an E_EVERYTHING constant which acts asE_ALLonce did: it
turns on all error reporting.I'm not terribly attached to either the names or, indeed, the request in
general, but it'd be nice to get this one closed one way or t'other.
I would like something like E_DEVELOPMENT (notices, warnings,
deprecated and the classic fatal), to strongly advice developers to
use it. On the same line, we could add E_PRODUCTION to set the error
reporting we recommend in production (fatal and warning).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I don't see it as an argument against as the fix is rather easy:
if (!defined('E_NONE')) {
...But it should not be added in a minor release.
Agreed. To be clear: the patch is against trunk, and I wouldn't
suggest it even be considered for 5.3.
Johannes has already said he wouldn't accept it for 5.3 anyway. :)
I would like something like E_DEVELOPMENT (notices, warnings,
deprecated and the classic fatal), to strongly advice developers to
use it. On the same line, we could add E_PRODUCTION to set the error
reporting we recommend in production (fatal and warning).
I'd be happy enough with E_DEVELOPMENT instead of E_EVERYTHING. The
point is that everything should be on — we should be encouraging
developers to fix up E_STRICT notices as well as the usual array of
things E_ALL shows.
Of course, another option is to put E_ALL back to truly being "all".
Adam
I'd be happy enough with E_DEVELOPMENT instead of E_EVERYTHING. The
point is that everything should be on — we should be encouraging
developers to fix upE_STRICTnotices as well as the usual array of
thingsE_ALLshows.
Don't we already have this with the default two php.inis we have in some
form?
Derick
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Don't we already have this with the default two php.inis we have in some
form?
Yes, we do. And I, for one, also do not see the point for new E_*
constants.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Don't we already have this with the default two php.inis we have in some
form?Yes, we do. And I, for one, also do not see the point for new E_*
constants.
Nobody uses the recommendation in the two php.inis. The point of
having those is to have them at the code level (keeping in mind that
many mainstream projects set the error level in their config). It also
brings a bit of clarity in these settings and where to use them.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Nobody uses the recommendation in the two php.inis.
So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
options to PHP that offer choices to developers. If they do not use
them ... what can we do?
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Nobody uses the recommendation in the two php.inis.
So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
options to PHP that offer choices to developers. If they do not use
them ... what can we do?
Simplify. I think I made my view clear earlier in this thread :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Sebastian Bergmann wrote:
So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
options to PHP that offer choices to developers. If they do not use
them ... what can we do?
As a regular user of PHP, I like the idea of E_DEVELOPMENT and
E_PRODUCTION. They're clear and will do what I would expect them to.
Why not change the default php.inis to those values instead?
I'm a against E_NONE, though. Now, I understand what a bit mask is, but
imagine for a second that I didn't. Imagine that I want no messages
except for E_ERROR. As a theoretically less experienced developer, I
might assume that I should explicitly turn off all errors except for
E_ERROR. What does that get me? error_reporting(E_NONE & E_ERROR).
Oops. That doesn't work as I expect it to!
Using a '0' makes it painfully obvious that it's not meant to combine
with the other predefined constants. 0 is special. 0 doesn't play
nicely with others.
This is obviously an edge case, and a less experienced developer would
hopefully learn very quickly the right way to do it, but I don't like
the idea of giving people ammo to shoot at PHP and its wacky E_* constants.
--
Tyler Lawson
Sebastian Bergmann wrote:
So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
options to PHP that offer choices to developers. If they do not use
them ... what can we do?As a regular user of PHP, I like the idea of E_DEVELOPMENT and
E_PRODUCTION. They're clear and will do what I would expect them to.
Why not change the default php.inis to those values instead?I'm a against E_NONE, though. Now, I understand what a bit mask is, but
imagine for a second that I didn't. Imagine that I want no messages
except for E_ERROR. As a theoretically less experienced developer, I
might assume that I should explicitly turn off all errors except for
E_ERROR. What does that get me? error_reporting(E_NONE & E_ERROR).
Oops. That doesn't work as I expect it to!
That's because you're doing it wrong:
error_reporting(E_NONE | E_ERROR);
- David
David Zülke wrote:
That's because you're doing it wrong:
error_reporting(E_NONE | E_ERROR);
- David
You're correct that I did it wrong and I apologize. Your example is how
it would be properly written out and it would work the way the
programmer expects it.
My point was that E_NONE has a different meaning than 0 - even if
E_NONE==0. I've never seen "error_reporting(0 | E_ERROR);" because
that's just silly. People who do understand bit masks would know it's
useless, and people who don't would just copy off the internet from
people who know better.
In short, I don't want to see "error_reporting(E_NONE | E_ERROR);" in
anybody's PHP code. Even if it is harmless.
Maybe I'm just a little too wound up about such things, though. Just my
two cents.
--
Tyler Lawson
Hi!
http://bugs.php.net/52563 suggests adding an E_NONE constant (set to 0) to
go with the various other E_* constants we have. I've hacked up a quick
I'm kind of confused - why we need E_NONE? In case value of 0 should
ever change?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
http://bugs.php.net/52563 suggests adding an E_NONE constant (set to 0) to
go with the various other E_* constants we have. I've hacked up a quickI'm kind of confused - why we need E_NONE? In case value of 0 should ever
change?
Rhetorical question: Why do we need constants when the values never change? :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
Rhetorical question: Why do we need constants when the values never change? :)
You seriously don't know why one needs constants or don't see a
difference between constant E_WARNING equal to 8 and constant E_NONE
meaning "nothing" and equal to 0? How about having constants ONE, TWO,
THREE, FOUR? Just in case, won't hurt anybody, right? :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
You seriously don't know why one needs constants or don't see a difference between constant
E_WARNINGequal to 8 and constant E_NONE meaning "nothing" and equal to 0? How about having constants ONE, TWO, THREE, FOUR? Just in case, won't hurt anybody, right? :)
Daily WTF is that way. :)
I didn't lodge the original request, but I thought the reasoning
behind E_NONE was pretty clear: it's pointless, sure, but it visually
lines up with the other E_ constants. At that point, you can just make
the advice when helping out PHP developers on support forums "always
use an E_ constant with error_reporting" and not have the current
situation where sometimes you use a constant (or constants) and
sometimes you use a bare number, depending on what you want to
achieve.
Aside from the potential conflict issue Johannes noted, I thought it
seemed pretty harmless.
Adam
Hi!
use an E_ constant with error_reporting" and not have the current
situation where sometimes you use a constant (or constants) and
sometimes you use a bare number, depending on what you want to
achieve.
What's wrong with using 0? 0 means "nothing", how hard is that? `
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
use an E_ constant with error_reporting" and not have the current
situation where sometimes you use a constant (or constants) and
sometimes you use a bare number, depending on what you want to
achieve.What's wrong with using 0? 0 means "nothing", how hard is that? `
The only downside is, that programmer will need to know, that E_*
constants do mean numbers.
With adding E_NONE this knowledge would be unnecessary and people
would be able just to think in terms of abstract "symbols"
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
The only downside is, that programmer will need to know, that E_*
constants do mean numbers.
With adding E_NONE this knowledge would be unnecessary and people
would be able just to think in terms of abstract "symbols"
Users should be aware of this being a bitmask in order to set proper
error modes like E_ALL & ~E_STRICT.
johannes
Hi!
use an E_ constant with error_reporting" and not have the current
situation where sometimes you use a constant (or constants) and
sometimes you use a bare number, depending on what you want to
achieve.What's wrong with using 0? 0 means "nothing", how hard is that? `
What's the problem actually? It is consistent with the rest. Yes, it
is always possible to add & 0 or || 1. But that's off base.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
use an E_ constant with error_reporting" and not have the current
situation where sometimes you use a constant (or constants) and
sometimes you use a bare number, depending on what you want to
achieve.What's wrong with using 0? 0 means "nothing", how hard is that? `
Nothing wrong in using 0, but it would be much more elegant to
stick to constants all from the same family. Someone already
figured that out:
$ php -r 'print_r(get_defined_constants());' | grep ' 0' | wc -l
89
Anyway, my opinion is I would like E_NONE in next major release,
and I would also like E_ALL to be extended to include E_DEPRECATED and
E_STRICT, instead of adding a really bogus E_DEVELOPMENT or E_EVERYTHING.
Please also note that E_* indicates a single error channel, with the
exception of E_ALL and possibly E_NONE if it gets added. I would avoid
adding more E_* constants which don't represent a single channel. I
would find it confusing.
2c
--
Giovanni Giacobbi
http://thedailywtf.com/Articles/Avoiding-Magic-Constants.aspx
I'm sorry, I could not resist.
On Tue, Aug 24, 2010 at 5:26 PM, Giovanni Giacobbi giovanni@giacobbi.netwrote:
Hi!
use an E_ constant with error_reporting" and not have the current
situation where sometimes you use a constant (or constants) and
sometimes you use a bare number, depending on what you want to
achieve.What's wrong with using 0? 0 means "nothing", how hard is that? `
Nothing wrong in using 0, but it would be much more elegant to
stick to constants all from the same family. Someone already
figured that out:$ php -r 'print_r(get_defined_constants());' | grep ' 0' | wc -l
89Anyway, my opinion is I would like E_NONE in next major release,
and I would also likeE_ALLto be extended to includeE_DEPRECATEDand
E_STRICT, instead of adding a really bogus E_DEVELOPMENT or E_EVERYTHING.Please also note that E_* indicates a single error channel, with the
exception ofE_ALLand possibly E_NONE if it gets added. I would avoid
adding more E_* constants which don't represent a single channel. I
would find it confusing.2c
--
Giovanni Giacobbi--
--
Nicolas A. Bérard-Nault (nicobn@gmail.com)
Hi!
Rhetorical question: Why do we need constants when the values never
change? :)You seriously don't know why one needs constants or don't see a difference
between constantE_WARNINGequal to 8 and constant E_NONE meaning "nothing"
and equal to 0? How about having constants ONE, TWO, THREE, FOUR? Just in
case, won't hurt anybody, right? :)
Do we have to stop add constants with obvious numbers? My obvious
number is 42 :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Stas,
Having E_FORTY_TWO would be super-useful ;-)
Hi!
Rhetorical question: Why do we need constants when the values never
change? :)You seriously don't know why one needs constants or don't see a difference
between constantE_WARNINGequal to 8 and constant E_NONE meaning "nothing"
and equal to 0? How about having constants ONE, TWO, THREE, FOUR? Just in
case, won't hurt anybody, right? :)Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
Having E_FORTY_TWO would be super-useful ;-)
FOURTY! Only to annoy all English teachers out there :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Stas,
Having E_FORTY_TWO would be super-useful ;-)
offtopic:
shouldn't be that E_ANSWER_TO_LIFE_UNIVERSE_AND_EVERYTHING?
maybe we should set E_ALL for 42 too. :)
-1 for E_DEVELOPMENT E_PRODUCTION E_EVERYTHING
+1 for the E_NONE
+1 for adding everything to E_ALL with the next major version
Tyrael
Stas,
Having E_FORTY_TWO would be super-useful ;-)
offtopic:
shouldn't be that E_ANSWER_TO_LIFE_UNIVERSE_AND_EVERYTHING?
maybe we should setE_ALLfor 42 too. :)-1 for E_DEVELOPMENT E_PRODUCTION E_EVERYTHING
+1 for the E_NONE
+1 for adding everything toE_ALLwith the next major versionTyrael
With all of "I thought this sort of stuff was for Friday's only"
comments being made, I think
E_ALL_AND_I_REALLY_REALLY_REALLY_DO_MEAN_ALL would be the most useful.
--
Richard Quadling.
2010/8/26 Richard Quadling rquadling@gmail.com:
With all of "I thought this sort of stuff was for Friday's only"
comments being made, I think
E_ALL_AND_I_REALLY_REALLY_REALLY_DO_MEAN_ALL would be the most useful.
Sorry to contradict you, but the most useful would be that:
error_reporting(E_CHUCK_NORRIS);
would silently repair the errors as well as correct them in the code
while blaming the authors!
Patrick
2010/8/26 Richard Quadling rquadling@gmail.com:
With all of "I thought this sort of stuff was for Friday's only"
comments being made, I think
E_ALL_AND_I_REALLY_REALLY_REALLY_DO_MEAN_ALL would be the most useful.Sorry to contradict you, but the most useful would be that:
error_reporting(E_CHUCK_NORRIS);
would silently repair the errors as well as correct them in the code
while blaming the authors!Patrick
E_MCGYVER and E_A_TEAM or E_LEVERAGE would all just get the job done,
either using what bits of code that were found lying about, blowing up
your rival servers or by stealing all your money.
--
Richard Quadling.
Johannes has pointed out on IRC that E_NONE does already exist in some
projects, so that's an argument against it.
Yeah, I did a quick code search, which gave some results defining a
constant with that name. This means adding this in 5.3 would be a
annoyance and upgrading from X.Y.(Z-1) to X.Y.Z should be a no
brainer ... on the other hand the fact that people are defining such a
constant and the bug report show that there is some need.
I myself don't see a point in a constant for an empty bit mask. As an
empty bit mask means 0 ... on the other hand it doesn't cost us much.
So, I'm +/- 0 on this for trunk.
johannes
Johannes Schlüter wrote:
Johannes has pointed out on IRC that E_NONE does already exist in some
projects, so that's an argument against it.Yeah, I did a quick code search, which gave some results defining a
constant with that name. This means adding this in 5.3 would be a
annoyance and upgrading from X.Y.(Z-1) to X.Y.Z should be a no
brainer ... on the other hand the fact that people are defining such a
constant and the bug report show that there is some need.I myself don't see a point in a constant for an empty bit mask. As an
empty bit mask means 0 ... on the other hand it doesn't cost us much.So, I'm +/- 0 on this for trunk.
'a quick code search' for '0' is not going to produce anything sensible, while a
quick code search for 'E_NONE' will (in theory) pick up all the places where
that particular setting is used. So there IS some sensible reason to add
'pointless' constants. The problem is - it only works if people DO use it
consistently ...
Given that many people are not used to the maze of code, improving navigability
by adding consistent 'pointless' constants could potentially help a lot, even if
the constant is simply added as a comment where a check for 0 does not actually
need the value?
--
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//
Firebird - http://www.firebirdsql.org/index.php
Johannes Schlüter wrote:
Johannes has pointed out on IRC that E_NONE does already exist in some
projects, so that's an argument against it.Yeah, I did a quick code search, which gave some results defining a
constant with that name. This means adding this in 5.3 would be a
annoyance and upgrading from X.Y.(Z-1) to X.Y.Z should be a no
brainer ... on the other hand the fact that people are defining such a
constant and the bug report show that there is some need.I myself don't see a point in a constant for an empty bit mask. As an
empty bit mask means 0 ... on the other hand it doesn't cost us much.So, I'm +/- 0 on this for trunk.
'a quick code search' for '0' is not going to produce anything sensible,
while a quick code search for 'E_NONE' will (in theory) pick up all the
places where that particular setting is used. So there IS some sensible
reason to add 'pointless' constants. The problem is - it only works if
people DO use it consistently ...
How many times do the E_XX constants appear without 'error_reporting'
next to it?
Given that many people are not used to the maze of code, improving
navigability by adding consistent 'pointless' constants could potentially
help a lot, even if the constant is simply added as a comment where a check
for 0 does not actually need the value?
I honestly see more value in the E_EVERYTHING than the E_NONE simply
because -1 seems to be more "magical" than 0; the fact that 'all' and
'everything' would mean different things is ... regrettable ;-)
--
Lester Caine - G8HFLContact - 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//
Firebird - http://www.firebirdsql.org/index.php--
--
Tjerk
Hi
2010/8/24 Adam Harvey aharvey@php.net:
Kalle also suggested another constant within that request to provide a
symbolic version of error_reporting = -1, so there's a second patch in that
report to add an E_EVERYTHING constant which acts asE_ALLonce did: it
turns on all error reporting.
On a personal level I only think E_ALL would make sense, because in
the old PHP6 E_STRICT were not apart of E_ALL, that is ofcourse, if
you choose not to use the "magic" -1 thats always contains all the
bits no matter what.
--
regards,
Kalle Sommer Nielsen
kalle@php.net