Re: Question: Should exit() print out the integer exit-status?
| From: | Vlad Krupin | Date: | Wed, 19 Dec 2001 18:36:22 +0000 |
| Subject: | Re: Question: Should exit() print out the integer exit-status? | ||
| References: | 1 2 3 4 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-74442@lists.php.net to get a copy of this message | ||
it's kinda lame to create a yet another function when exit() already exists. After a while you have die(), exit(), exit_with_status(),
silent_exit(), loud_exit(), etc. Maybe not *that* bad, but still exit is just as simple as... well, an exit. Unfortunately, it seems like there will be tons of ways to do a simple operation. Now, imagine you are just starting out with PHP - will you be looking for a whole array of exit() functions, or will you just try to use the one that seems to make sense, namely exit()?
It's not really just an exit() function issue - it is more a question of whether we will keep bloating php with more and more functions to save BC at any cost or we will draw a line somewhere. As it is right now, IMHO, exit with an error code is broken (I just can't see people needing that error code printed), and I really don't think that keeping BC intact to keep broken things working warrants creation of a new function, which mimicks the already existent function, except in a proper way.
As far as the bigger picture, we have no guidelines as to what warrants breaking BC, and if fixing a broken behaviour constitutes breaking BC. Every time this comes up (and it has come up quite a bit lately), there is a big discussion, and the decision inevitably ends up being "we'll just break it at the next major/minor version". This is a good step, but (1) a new major version does not warrant breaking everything, (2) things that are totally wrong should get fixed ASAP, because they are already broken, and (3) you can not bloat a language indefinitely just for the sake of BC, because it ends up being *very* backwards compatible, and at the same time *very* cumbersome and harder to learn for new users.
No, I don't have any suggestions as to what to do when those cases (like fixing exit()/ fixing docs/ bloating php) arise, but I do think that we can have some discussion about it and use it later as some sort of a precedent for these kinds of issues.
:) (I'm a friendly guy, don't kill me for expressing my opinions)
Vlad
Zeev Suraski wrote:
exit_with_status(), silent_exit(), quiet_exit(), etc. etc. Something should fit :) At 14:49 19/12/2001, Lars Torben Wilson wrote:Zeev Suraski writes:At 14:04 19/12/2001, derick@php.net wrote:Two ways to fix it then, either update the manual, or fix exit(). I go for the last one then. Ppl who relied on the undocumented feature then, did simply the wrong thing.Only the documentation was wrong to begin with! A documentationbug shouldnot become a feature, especially when it never worked that way, soanybodywho actually used this function saw that it was behaving differently. ZeevWell, from another point of view, both were wrong. :) The manual documented behaviour which didn't exist, so it was wrong. In another sense, the code behaved in a fashion which had a very high WTF factor, so it couild be called 'wrong' too. An easy way to set and check the exit status of a PHP script would make a lot of life a hell of a lot easier. -- Torben Wilson <torben@php.net> http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506