# [RFC] E_DEPRECATED - Thread: https://externals.io/message/26196 - Original archive: https://news-web.php.net/php.internals/26196 - Started by Marcus Boerger on 2006-10-23T19:08:57+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/26196.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 --- ## #26196 — Marcus Boerger — 2006-10-23T19:08:57+00:00 URL: https://externals.io/message/26196#26196 Hello internals, after recent discussions (over the last three months)I finally made up my mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea proposal is to do the following: - Add a new severity `E_DEPRECATED` - severities are used as follows: . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst removal would be two minor versions or one major version later. That is something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. However both marking it as deprecated as well as removing it would require a consensus on the list. . `E_STRICT` any rule that reflects common strict standards, like OOP theory that is considered harmless if not followed. For example the combination 'abstract static' makes no sense in said theory but doesn't put our zend engine in an unstable state. . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. domain errors). - We drop the current standard INI files and provide two new, namely . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) . php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING)) . `E_ALL` does not contain `E_STRICT` or `E_DEPRECATED` - We delay 5.2.0 and revisit all errors and change them according to the new model. We also put any change into the upgrading file. You may respond with constructive ideas or complaints or go voting for all or single points here, use -1, 0, +1 only. Please do not reply for the sake of responding, use pure voting instead as we are running out of time for 5.2.0 otherwise. Best regards, Marcus --- ## #26197 — Steph Fox — 2006-10-23T19:19:00+00:00 URL: https://externals.io/message/26196#26197 · In reply to: #26196 Hi Marcus, +1 to everything here if it counts, but please can you simplify the role of `E_DEPRECATED` by making it 'next major version only'? I can see all kinds of problems with leaving that open to debate. - Steph > Hello internals, > > after recent discussions (over the last three months)I finally made up my > mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea > proposal is to do the following: > > - Add a new severity `E_DEPRECATED` > > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. > Eearlierst > removal would be two minor versions or one major version later. That is > something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. > . `E_STRICT` any rule that reflects common strict standards, like OOP > theory > that is considered harmless if not followed. For example the > combination > 'abstract static' makes no sense in said theory but doesn't put our > zend > engine in an unstable state. > . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. domain > errors). > > - We drop the current standard INI files and provide two new, namely > . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) > . php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING)) > . `E_ALL` does not contain `E_STRICT` or `E_DEPRECATED` > > - We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. > > You may respond with constructive ideas or complaints or go voting for all > or single points here, use -1, 0, +1 only. Please do not reply for the > sake > of responding, use pure voting instead as we are running out of time for > 5.2.0 otherwise. > > Best regards, > Marcus --- ## #26198 — Pierre — 2006-10-23T19:29:31+00:00 URL: https://externals.io/message/26196#26198 · In reply to: #26196 On Mon, 23 Oct 2006 21:08:57 +0200 helly@php.net (Marcus Boerger) wrote: > Hello internals, > > after recent discussions (over the last three months)I finally made > up my mind over E_STRICT, deprecation warnings and OOP > messages/rules. My idea proposal is to do the following: > > - Add a new severity `E_DEPRECATED` > > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. > Eearlierst removal would be two minor versions or one major version > later. That is something that gets deprecated in 5.2 can be removed > in 5.4.0 or 6.0.0. However both marking it as deprecated as well as > removing it would require a consensus on the list. +1 If removed in the next major version only. -1 otherwise. It is already a nightmare to remember or manage the various changes in all last minor releases. > You may respond with constructive ideas or complaints or go voting > for all or single points here, use -1, 0, +1 only. Please do not > reply for the sake of responding, use pure voting instead as we are > running out of time for 5.2.0 otherwise. +1 for the other points, even if we can expect 5.2.0 for early 2007 ;-) -- Pierre --- ## #26199 — Derick Rethans — 2006-10-23T19:33:39+00:00 URL: https://externals.io/message/26196#26199 · In reply to: #26196 > after recent discussions (over the last three months)I finally made up my > mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea > proposal is to do the following: > > - Add a new severity `E_DEPRECATED` +1 > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst > removal would be two minor versions or one major version later. That is > something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. +1 > . `E_STRICT` any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. +1, but then we should also expand this to include: - setting object variables without declaring them - auto-creating objects of stdclass on the fly - and other things that you *should* (not) do These can be added later ofcourse, doesn't have to be directly in 5.2.0, however that would probably be better. > . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. domain errors). +1, but I think we need to specify when exactly to use E_NOTICE, E_WARNING, `E_RECOVERABLE_ERROR` and `E_ERROR` as well. > - We drop the current standard INI files and provide two new, namely > . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) > . php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING)) > . `E_ALL` does not contain `E_STRICT` or `E_DEPRECATED` -1, We should include `E_DEPRECATED` in E_ALL. > - We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. +1 regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #26200 — Robert Cummings — 2006-10-23T19:34:44+00:00 URL: https://externals.io/message/26196#26200 · In reply to: #26198 > On Mon, 23 Oct 2006 21:08:57 +0200 > helly@php.net (Marcus Boerger) wrote: > > > […] > > +1 If removed in the next major version only. -1 otherwise. +1 with same sentiments. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' --- ## #26201 — Ilia Alshanetsky — 2006-10-23T19:46:28+00:00 URL: https://externals.io/message/26196#26201 · In reply to: #26196 > - Add a new severity `E_DEPRECATED` > > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. > Eearlierst > removal would be two minor versions or one major version later. > That is > something that gets deprecated in 5.2 can be removed in 5.4.0 > or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. +1 as long as a removal is set, not the "we may or may not remove this, but here is a warning anyway". Once a component is marked with E_DEPRECATED, the next major release it is out. > . `E_STRICT` any rule that reflects common strict standards, like > OOP theory > that is considered harmless if not followed. For example the > combination > 'abstract static' makes no sense in said theory but doesn't put > our zend > engine in an unstable state. > . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. > domain errors). -1 In this case it seems like a pointless error level to me just killing cycles. If you are not using questionable behavior that has side-effects, why bother the user? > - We drop the current standard INI files and provide two new, namely > . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) > . php-production.ini for production (~(E_DEPRECATED|E_NOTICE| > E_WARNING)) > . `E_ALL` does not contain `E_STRICT` or `E_DEPRECATED` Rename rather then drop. > - We delay 5.2.0 and revisit all errors and change them according > to the > new model. We also put any change into the upgrading file. -1 (not happening) Ilia Alshanetsky --- ## #26202 — Richard Lynch — 2006-10-23T19:49:03+00:00 URL: https://externals.io/message/26196#26202 · In reply to: #26196 > Hello internals, +1, ditto on only major version for `E_DEPRECATED` to disappear I'd go either way on `E_ALL` changing -- but would think that the Right Thing is to leave it alone in 5.2, but make it mean *ALL* (even E_STRICT) in 6.0 -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #26203 — Alan Milnes — 2006-10-23T19:54:13+00:00 URL: https://externals.io/message/26196#26203 · In reply to: #26196 Marcus Boerger wrote: > Hello internals, > > after recent discussions (over the last three months)I finally made up my > mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea > proposal is to do the following: +1 to them all. Alan --- ## #26208 — Edin Kadribasic — 2006-10-23T21:59:46+00:00 URL: https://externals.io/message/26196#26208 · In reply to: #26196 Marcus Boerger wrote: > Hello internals, > > after recent discussions (over the last three months)I finally made up my > mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea > proposal is to do the following: > > - Add a new severity `E_DEPRECATED` > > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst > removal would be two minor versions or one major version later. That is > something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. > . `E_STRICT` any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. > . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. domain errors). +1 > - We drop the current standard INI files and provide two new, namely > . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) > . php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING)) > . `E_ALL` does not contain `E_STRICT` or `E_DEPRECATED` +1 > - We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. +1 > You may respond with constructive ideas or complaints or go voting for all > or single points here, use -1, 0, +1 only. Please do not reply for the sake > of responding, use pure voting instead as we are running out of time for > 5.2.0 otherwise. > > Best regards, > Marcus Edin --- ## #26209 — Edin Kadribasic — 2006-10-23T22:03:09+00:00 URL: https://externals.io/message/26196#26209 · In reply to: #26199 Derick Rethans wrote: > > […] > > +1, but then we should also expand this to include: > > - setting object variables without declaring them > - auto-creating objects of stdclass on the fly > - and other things that you *should* (not) do > > These can be added later ofcourse, doesn't have to be directly in > 5.2.0, however that would probably be better. I'm -1 on expanding strictness to this. I don't understand why you should not do this? Writing mydb_fetch_object() becomes impossible in userspace if we go this far. It would also make any legal use of stdClass impossible. Edin --- ## #26210 — Todd Ruth — 2006-10-23T23:12:15+00:00 URL: https://externals.io/message/26196#26210 · In reply to: #26209 I'm not a voter, but I'd like to lobby for a fancier E_STRICT... `E_STRICT` is sounding more and more like runtime "lint". I very much miss lint. (I'm sure it's still around, but I've been programming in only php for the last few years.) A key feature of lint that made it usable was that you could have a file listing error codes that you always wanted to ignore and you could use a comment adjacent to your "bad" code to tell lint to ignore that specific case. I think a previous thread talked about using codes in the messages to allow easy bulk filtering, so the file of codes to skip isn't absolutely necessary. Being able to put in a comment that causes the `E_STRICT` to be skipped for an adjacent bit of "bad" code would be very friendly. We make sure all of our code is NOTICE free (for as many code paths as we can stand to test) before it goes out the door. I'm sure many others do the same. To be able to do the same with `E_STRICT` would be a great benefit, but I think a larger portion of the user base would adopt it if there were ways to turn down the volume when you really want to ignore "the guidelines for ideal code". I have no idea how difficult such a feature would be; I just wanted to point out how useful it would be. (As always, thanks for all that all of you do!) BTW, the trend on the list toward separating STRICT and DEPRECATED and only putting deadly stuff in the DEPRECATED bin is very much appreciated. For a while I was guessing we'd never be able to upgrade our php! I'm still assuming 5.2 is unusable based on the threads about fatal errors, but it seems all this will be sorted out for 5.3 at the latest. That's better than being on 5.1 for the rest of our lives. Thanks, Todd --- ## #26213 — Sebastian Bergmann — 2006-10-24T00:04:43+00:00 URL: https://externals.io/message/26196#26213 · In reply to: #26196 Marcus Boerger wrote: > - Add a new severity `E_DEPRECATED` +1 > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst > removal would be two minor versions or one major version later. That is > something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. > . `E_STRICT` any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. > . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. domain errors). +1 > - We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. +1 -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #26215 — Wez Furlong — 2006-10-24T01:17:37+00:00 URL: https://externals.io/message/26196#26215 · In reply to: #26196 > . E_DEPRECATED: Some language featre that is likely to go away. s/likely/confirmed/. We can't speculatively deprecate a feature and then change our minds. (The {} vs [] thing with strings comes to mind). I don't think we need to set any firm ground rules for the deprecation timeline but should consider each change individually. A reasonable rule of thumb is to remove deprecated features no sooner than 1 minor release after the deprecation notice was added. Ideally, it should be in a major release. +1 > . `E_STRICT` any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. +1 Note that if we are going to treat implicit property setting as `E_STRICT` then we should exclude stdClass from generating those warnings, otherwise you can't work with deliberately created dynamic objects. > - We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. +0. Let's just delay 5.2 long enough to make sure we haven't accidentally promoted `E_STRICT` to fatal errors in 5.2. --Wez. --- ## #26217 — Zeev Suraski — 2006-10-24T05:53:27+00:00 URL: https://externals.io/message/26196#26217 · In reply to: #26196 At 21:08 23/10/2006, Marcus Boerger wrote: >Hello internals, > > after recent discussions (over the last three months)I finally made up my >mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea >proposal is to do the following: > >- Add a new severity `E_DEPRECATED` > >- severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst > removal would be two minor versions or one major version later. That is > something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. > . `E_STRICT` any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. > . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. > domain errors). +1 >- We drop the current standard INI files and provide two new, namely > . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) > . php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING)) > . `E_ALL` does not contain `E_STRICT` or `E_DEPRECATED` -1 I don't think we should change the names. A bunch of the -recommended changes from the default file have nothing to do with development/production, so differentiating based on that is not accurate. Avoiding renames will also reduce the chance of confusion (no big deal, but even the tiniest changes in such a central piece tend to trigger questions). I personally also don't see a good reason to disable `E_WARNING` and `E_NOTICE` (and possibly also E_DEPRECATED) in a production environment - you may still want to log such errors. As long as display_errors is off, it's not a problem except for the performance hit which should be low assuming you don't have too many of them. >- We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. +1 Zeev --- ## #26219 — Derick Rethans — 2006-10-24T07:05:45+00:00 URL: https://externals.io/message/26196#26219 · In reply to: #26209 > Derick Rethans wrote: > > […] > > I'm -1 on expanding strictness to this. I don't understand why you > should not do this? Because atleast those two points should usually *never* happen in a serious application. They're very often just typoes and make debugging harder. As I know you don't care about that, simply don't turn on E_STRICT... > Writing mydb_fetch_object() becomes impossible in > userspace if we go this far. It would also make any legal use of > stdClass impossible. Yes, but in the "strict" world, there is no legal use for stdClass in the first place. regards, Derick --- ## #26220 — Jasper Bryant-Greene — 2006-10-24T07:21:41+00:00 URL: https://externals.io/message/26196#26220 · In reply to: #26219 Derick Rethans wrote: > > > […] > > Yes, but in the "strict" world, there is no legal use for stdClass in > the first place. I've got to agree with this and Derick's other points. I've written or been involved in writing a great many larger PHP applications, all of which have aimed to be `E_STRICT` clean, and have never, ever used stdClass. I can't see a reason why you would want to, as it's effectively an associative array with syntax that fools people into thinking you're writing OO code :> As to mydb_fetch_object()... what was wrong with mydb_fetch_assoc()? What does mydb_fetch_object() add to it other than aforementioned syntax that pretends to be OO? -- Jasper Bryant-Greene Director Album Limited jasper@albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/ --- ## #26222 — Lukas Kahwe Smith — 2006-10-24T07:32:49+00:00 URL: https://externals.io/message/26196#26222 · In reply to: #26215 Wez Furlong wrote: > I don't think we need to set any firm ground rules for the deprecation > timeline but should consider each change individually. A reasonable > rule of thumb is to remove deprecated features no sooner than 1 minor > release after the deprecation notice was added. Ideally, it should be > in a major release. I think we should have a firm rule, such as: At every major version we grep through the code base for stuff marked as deprecated and if there is not a really really good reason someone comes up with its out. Any rule should be superseded by common sense anyways. regards, Lukas --- ## #26223 — Richard Quadling — 2006-10-24T08:39:31+00:00 URL: https://externals.io/message/26196#26223 · In reply to: #26196 My vote (if it counts - can someone let me know if it does?) > Hello internals, > > after recent discussions (over the last three months)I finally made up my > mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea > proposal is to do the following: > > - Add a new severity `E_DEPRECATED` +1 - Absolutely. > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst > removal would be two minor versions or one major version later. That is > something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. +1 - At a major release would seem more appropriate, though deprecating something near the end of the previous major release could seem to be too quick. > . `E_STRICT` any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. +1 - As an aside, it would be extremely useful to have the PEAR classes marked as NON strict (in some way) until they are. I know this is outside of the core, but using `E_STRICT` already means you have to toggle off `E_STRICT` for PEAR. MAYBE STRICT (e.g. strict class PEAR {...}) as a new keyword for a class, just so that you know that it IS strict (or at least expecting to be). > . `E_NOTICE` or `E_WARNING` are used for input validations (e.g. domain errors). +1/0 - Is this any different to what we already have? > > - We drop the current standard INI files and provide two new, namely > . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) > . php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING)) > . `E_ALL` does not contain `E_STRICT` or `E_DEPRECATED` > -1 : As mentioned, if the developed code is notice/strict clean (and it sure as hell should be), then the only major difference is displaying of errors. The use of error and exception handlers should be promoted to reduce the requirement of hiding errors. > - We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. -1 : Whilst I would like to have everything and the kitchen sink in PHP (I've got one in FireFox - actually doesn't make it any better though), the longer the delay, the more problems there seems to be. Have the cut off and fix faster! (Ok - that's just me being funny. Or not! You are all working VERY hard to get this working for us, well, me and all I do is make bad comments - but hey! Ain't open source great? Community spirit and all that! Everyone chipping in with their 2cents worth ...) > You may respond with constructive ideas or complaints or go voting for all > or single points here, use -1, 0, +1 only. Please do not reply for the sake > of responding, use pure voting instead as we are running out of time for > 5.2.0 otherwise. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26224 — Lukas Kahwe Smith — 2006-10-24T12:41:42+00:00 URL: https://externals.io/message/26196#26224 · In reply to: #26223 Richard Quadling wrote: > +1 - As an aside, it would be extremely useful to have the PEAR > classes marked as NON strict (in some way) until they are. I know this > is outside of the core, but using `E_STRICT` already means you have to > toggle off `E_STRICT` for PEAR. MAYBE STRICT (e.g. strict class PEAR > {...}) as a new keyword for a class, just so that you know that it IS > strict (or at least expecting to be). heh .. no that would not be useful .. it would be lying. PEAR already has decided on an RFC that will mandate PHP5 only for new packages soon. Also PEAR mandates `E_STRICT` compliance for PHP5 only packages. So time will fix this issue. regards, Lukas --- ## #26225 — Richard Quadling — 2006-10-24T12:44:19+00:00 URL: https://externals.io/message/26196#26225 · In reply to: #26224 > Richard Quadling wrote: > > > […] > > heh .. no that would not be useful .. it would be lying. PEAR already > has decided on an RFC that will mandate PHP5 only for new packages soon. > Also PEAR mandates `E_STRICT` compliance for PHP5 only packages. So time > will fix this issue. Ah. Oh. Excellent. Didn't know that. Thank you. (Balancing ... balancing ...) -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26235 — mgagne@generationphp.net — 2006-10-24T19:22:47+00:00 URL: https://externals.io/message/26196#26235 · In reply to: #26217 Hi, > I personally also don't see a good reason to disable `E_WARNING` and > `E_NOTICE` (and possibly also E_DEPRECATED) in a production environment - > you may still want to log such errors. As long as display_errors is > off, it's not a problem except for the performance hit which should be > low assuming you don't have too many of them. As a system administrator, I must disagree with your opinion as most users don't care about error_log file. I have see a lot of servers with about 6GB of error_log filled with `E_NOTICE` AND E_WARNING. Just letting it enabled by default in production is a bad idea. Those notices should only be enabled during development since production is no more the time to do such debugging. -- Mathieu --- ## #26237 — Jasper Bryant-Greene — 2006-10-24T21:57:38+00:00 URL: https://externals.io/message/26196#26237 · In reply to: #26235 Mathieu Gagné wrote: > > […] > > As a system administrator, I must disagree with your opinion as most > users don't care about error_log file. I have see a lot of servers with > about 6GB of error_log filled with `E_NOTICE` AND E_WARNING. I would consider this the sysadmin's fault for letting logs grow without bounds. Surely you have heard of log rotation? > Just letting it enabled by default in production is a bad idea. Those > notices should only be enabled during development since production is no > more the time to do such debugging. If you have debugged your code well, and got rid of all the E_WARNING/E_NOTICE that you can, then surely you would want to know if a new one crops up? I see no problem with having E_WARNING/E_NOTICE enabled. `E_DEPRECATED` is another thing though. Enabling this by default is good because you will notice when code you are using becomes deprecated. However it probably shouldn't be enabled in production as you should be upgrading PHP on a development/testing/staging system before you do so on a live server! -- Jasper Bryant-Greene Director Album Limited jasper@albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/ --- ## #26238 — Ilia Alshanetsky — 2006-10-24T22:01:54+00:00 URL: https://externals.io/message/26196#26238 · In reply to: #26235 > ]As a system administrator, I must disagree with your opinion as > most users don't care about error_log file. I have see a lot of > servers with about 6GB of error_log filled with `E_NOTICE` AND > E_WARNING. Many ISPs often make 2 mistakes when it comes to log files. First they make all users use the same one, which means you potentially have hundreds of applications dumping errors into the same file making it grow quickly and impossible to find something in it. Which discourages users from looking in those files. The second mistake is often not giving the users access to the file or simply not letting them know where such a file can be found. Ilia Alshanetsky --- ## #26241 — Richard Quadling — 2006-10-25T07:35:25+00:00 URL: https://externals.io/message/26196#26241 · In reply to: #26235 > Hi, > > > […] > > As a system administrator, I must disagree with your opinion as most > users don't care about error_log file. I have see a lot of servers with > about 6GB of error_log filled with `E_NOTICE` AND E_WARNING. > > Just letting it enabled by default in production is a bad idea. Those > notices should only be enabled during development since production is no > more the time to do such debugging. As I run my own servers, I'm forgetful of the laziness of some ISPs. So, yes I can see that having them enabled COULD be considered a bad thing, BUT again, it is education to train people to write code which doesn't produce WENDS (Warnings/Errors/Notices/Deprecated/Strict). And for those lazy ISPs, it will make little difference what the setting is anyway. If they have a 6GB error file now, then having one a little bigger really isn't that much of concern. The benefit though is that WENDS can still be generated in a production environment and I would sure as hell want to see them in a log file. Often the production environment is not 100% identical to the development environment (different memory, speed, loading, etc). Or to paraphase Forrest Gump, "Shit Happens!". -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26252 — Christian Schneider — 2006-10-25T14:56:12+00:00 URL: https://externals.io/message/26196#26252 · In reply to: #26196 Marcus Boerger wrote: > - Add a new severity `E_DEPRECATED` Sounds like a good idea, +1 on the whole thing. > . `E_STRICT` any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. Another idea (I haven't seen skimming through the replies): Move use of undefined variable, property and index from `E_NOTICE` to `E_STRICT` as it is a coding style question some people use to find typos. Regards, - Chris --- Next page: https://externals.io/message/26196.md?page=2