Re: Re: PHP-4.0.7RC1
| From: | Zeev Suraski | Date: | Fri, 17 Aug 2001 14:48:35 +0000 |
| Subject: | Re: Re: PHP-4.0.7RC1 | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.dev php.qa |
| Request: | Send a blank email to php-dev+get-63531@lists.php.net to get a copy of this message | ||
At 17:43 17-08-01, Hellekin O. Wolf wrote:
*** I understood that 4.0.7 / 4.1.0 would be a question of what we want next.4.1.0 will. We're not changing any defaults in 4.0.7...
If E_ALL brings better code, why not encourage that ? Democracy is good as long as it's evolving. If we encourage a default lax behavior, lax coders we'll have. If we encourage tighter programming, even the novice can cope with it and learn faster, and make less mistakes, etc. Is that too optimistic ? Or am I forgetting the existing code base ?I think it's a bit too optimistic, not to mention the existing code base :)
I think that as $HTTP_*_VARS disappear, lots of people will have to change that (Search/Replace + delete the corresponding "global" calls) anyway in order to use the new $_* arrays in future versions.There's a fundamental difference - setting E_NOTICE on means you have to audit *all* of your code, and in some cases, think about every possible execution path, just to see if you have a problem. While the HTTP_*_VARS is an easy S&R issue, and even setting register_globals off affects only the form-interface part of the application and is usually also an issue of S&R (slower, but still S&R), there's no way to fix all notices in a quick way. Even if you find the problems (which is very time consuming), fixing them can't be done using S&R, and it sometimes even requires changes to the logic. It's not that "While we're at it" type of action, it has considerable additional implications.
It's probably better to bother people once for good instead of once every version. The purpose of 4.0.* vs .4.1.* should be clear for all : it's a new step and you have to make it.First off, nobody *has* to do anything. They can always use an old version, or if we screw up too badly, switch to something else (I think the register_globals thing alone will take at least a year to catch, especially considering we're not eliminating the ability to turn it on). We're walking on a fine line here, between keeping PHP's ease of use and cleanliness. PHP is *definitely* not the cleanest language around, and it's not meant to be, either. That's why not every action that would result in a 'cleaner' language is automatically applied. Zeev