Vlad Krupin writes:
> Lars Torben Wilson wrote:
> >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.
> >
> Yikes. This is way worse than overloading. In school they called that
> data-coupling, I think. In real life this is called a hack.
>
> Sorry, but a -1 on this.
>
> Vlad
No, it's called loose typing. See
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
We have a language here which considers the integer value of "5" to
be 5, and an exit() construct which ignores that.
For instance:
shanna% php -q
<?php exit('5'); ?>
5
shanna% echo $?
0
shanna% php -q
<?php exit(5); ?>
5
shanna% echo $?
5
How much sense does this make? None, as far as I can see.
What I'm proposing is to make the behaviour of exit() _not_ depend on
the type of its argument. At present if the argument is an integer
exit() prints it and sets the error status, but if it's any other
type, exit() just prints it and doesn't set the exit status. This is
more complex than my proposal: no matter what the argument is, print
out its string value, and set the exit status to its integer value.
AFAICT exit() is currently broken wrt how it handles the type of its
argument.
--
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]
