# [PATCH] #52563: Adding E_NONE and/or E_EVERYTHING constants - Thread: https://externals.io/message/49488 - Original archive: https://news-web.php.net/php.internals/49488 - Started by Adam Harvey on 2010-08-24T10:49:13+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/49488.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49488 — Adam Harvey — 2010-08-24T10:49:13+00:00 URL: https://externals.io/message/49488#49488 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 --- ## #49489 — Pierre Joye — 2010-08-24T13:46:20+00:00 URL: https://externals.io/message/49488#49489 · In reply to: #49488 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 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. 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 --- ## #49490 — Adam Harvey — 2010-08-24T13:54:08+00:00 URL: https://externals.io/message/49488#49490 · In reply to: #49489 > 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 --- ## #49491 — Stas Malyshev — 2010-08-24T16:27:54+00:00 URL: https://externals.io/message/49488#49491 · In reply to: #49488 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 --- ## #49492 — Pierre Joye — 2010-08-24T17:44:26+00:00 URL: https://externals.io/message/49488#49492 · In reply to: #49491 > > […] > > I'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 --- ## #49493 — Stas Malyshev — 2010-08-24T17:47:17+00:00 URL: https://externals.io/message/49488#49493 · In reply to: #49492 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 --- ## #49494 — Adam Harvey — 2010-08-24T17:53:21+00:00 URL: https://externals.io/message/49488#49494 · In reply to: #49493 > 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? :) 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 --- ## #49495 — Pierre Joye — 2010-08-24T18:00:47+00:00 URL: https://externals.io/message/49488#49495 · In reply to: #49493 > Hi! > > > […] > > 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? :) 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 --- ## #49497 — Stas Malyshev — 2010-08-24T18:14:05+00:00 URL: https://externals.io/message/49488#49497 · In reply to: #49494 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 --- ## #49498 — Alexey Zakhlestin — 2010-08-24T18:23:04+00:00 URL: https://externals.io/message/49488#49498 · In reply to: #49497 > Hi! > > > […] > > 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/ --- ## #49499 — johannes@schlueters.de — 2010-08-24T18:27:43+00:00 URL: https://externals.io/message/49488#49499 · In reply to: #49488 > 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 --- ## #49500 — Pierre Joye — 2010-08-24T18:33:05+00:00 URL: https://externals.io/message/49488#49500 · In reply to: #49497 > Hi! > > > […] > > 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 --- ## #49501 — johannes@schlueters.de — 2010-08-24T20:31:59+00:00 URL: https://externals.io/message/49488#49501 · In reply to: #49498 > 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 --- ## #49502 — Giovanni Giacobbi — 2010-08-24T21:26:09+00:00 URL: https://externals.io/message/49488#49502 · In reply to: #49497 > Hi! > > > […] > > 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 --- ## #49504 — nicobn@gmail.com — 2010-08-25T02:38:49+00:00 URL: https://externals.io/message/49488#49504 · In reply to: #49502 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 wrote: > > > […] > > 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 > > -- > > > > -- Nicolas A. Bérard-Nault (nicobn@gmail.com) --- ## #49505 — Lester Caine — 2010-08-25T06:22:10+00:00 URL: https://externals.io/message/49488#49505 · In reply to: #49499 Johannes Schlüter wrote: > > > […] > > 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 --- ## #49506 — Tjerk Anne Meesters — 2010-08-25T06:58:55+00:00 URL: https://externals.io/message/49488#49506 · In reply to: #49505 > Johannes Schlüter wrote: > > […] > > '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 - 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 > > -- > > > > -- -- Tjerk --- ## #49508 — Derick Rethans — 2010-08-25T13:07:34+00:00 URL: https://externals.io/message/49488#49508 · In reply to: #49490 > 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. 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 --- ## #49510 — Sebastian Bergmann — 2010-08-25T13:34:21+00:00 URL: https://externals.io/message/49488#49510 · In reply to: #49508 > 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/ --- ## #49511 — Pierre Joye — 2010-08-25T13:38:45+00:00 URL: https://externals.io/message/49488#49511 · In reply to: #49510 > > > […] > >  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 --- ## #49512 — Sebastian Bergmann — 2010-08-25T13:44:47+00:00 URL: https://externals.io/message/49488#49512 · In reply to: #49511 > 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/ --- ## #49513 — Pierre Joye — 2010-08-25T13:49:48+00:00 URL: https://externals.io/message/49488#49513 · In reply to: #49512 > > > […] > >  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 --- ## #49514 — Tyler Lawson — 2010-08-25T13:51:20+00:00 URL: https://externals.io/message/49488#49514 · In reply to: #49512 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 --- ## #49515 — david.zuelke@bitextender.com — 2010-08-25T14:17:50+00:00 URL: https://externals.io/message/49488#49515 · In reply to: #49514 > Sebastian Bergmann wrote: > > > […] > > 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 --- ## #49516 — Kalle Sommer Nielsen — 2010-08-25T15:42:52+00:00 URL: https://externals.io/message/49488#49516 · In reply to: #49488 Hi 2010/8/24 Adam Harvey : > 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. 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 --- Next page: https://externals.io/message/49488.md?page=2