Zeev Suraski writes:
> At 15:15 19/12/2001, Lars Torben Wilson wrote:
> >Zeev Suraski writes:
> > > exit_with_status(), silent_exit(), quiet_exit(), etc. etc. Something
> > > should fit :)
> >
> >Yeah, you could do that. But then, why don't we have a
> >'c_compatible_dirname()' now, instead of a proper dirname() patch
> >which has been proven to break BC? Because the new version is Correct--at
> >least according to programming tradition. (Sorry, Manuel.) A function
> >named exit(), which accepts an argument, is just _expected_ to set the
> >exit status (assuming the coder has coded in other languages before).
> >
> >A better solution IMHO would be to make exit() do the right thing and
> >create a new function named something like 'exit_print()' which
> >behaves the way the current exit() does.
> >
> >Besides, as Vlad pointed out it's a _hell_ of a lot easier to do
> >the print-out thing in userland than it is to set the exit status. :)
>
> It's not about whether or not it's easy or not - we're not at the stage of
> designing the language behavior from scratch now...
>
> There's a fundamental difference between dirname(), which is supposed to
> answer the question of 'what directory does this file sit in?' - and
> there's only one correct answer. The old dirname() had a bug, period.
> What a function named exit() does is entirely up to us. Of course, it's
> expected to terminate execution by its very name, but it may do other
> things too, such as set the OS error code, print out an error message, etc.
Perhaps I have not explained my position. I don't care whether it
outputs the exit status as a string--as long as it sets the error code
appropriately *as well*. By appropriately, I mean that 'exit("boo");'
would a) print 'boo' and b) return with exit status 0, but
'exit("1boo")'; would a) print '1boo' and b) return with exit status
1. This would be consistent with PHP's type conversion rules, and
would also tend to behave in the way that the programmer expects it
to.
> exit(), since its introduction to PHP, had two usages:
> - Terminate script execution
> - Terminate script execution with an error message
>
> Changing it is out of the question, as:
> - Thousands of scripts rely on it
> - There's no 'right' or 'wrong' here, unlike dirname(). I personally find
> the current behavior to be much more useful, as I don't use PHP to create
> shell scripts, and I do use it to create Web apps. exit(reason) makes good
> sense to me.
>
> Changing it to be overloaded is a possibility, but a bad one IMHO, because:
> - Some scripts rely on it to behave as it always did (I have one such script)
> - It's inconsistent
I agree. That's why I think it should
a) Print out whatever it is given as an argument, and
b) Set the exit status to whatever its argument evaluates to as an int.
This is not overriding, per se. It's just being language-consistent.
> Drawbacks to using a new name:
> - Slightly longer to type (negligible)
> - Not obvious to somebody with a background of other languages that support
> exit(exit_code). This may be an issue, but I don't think it outweighs the
> advantages of staying with the current behavior.
>
> Zeev
>
--
Torben Wilson <[EMAIL PROTECTED]>
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
