Markus Fischer writes:
> Why not just check the type of the parameter? No conversion
> needed at all. If its a long -> exit/no show it. If anything
> else (well, thats to argue, but not the point) exit and show.
> It would be that easy. And, in that case, I don't care about
> the number of broken scripts. Prove there are more then you
> got fingers on your hand. And even those, you can fix under a
> second.
Because then exit('5') and exit(5) would still have different
behaviours, which is the current situation and which is the root of
the problem. If the implicit conversions are done, we end up with:
exit('5') : prints '5' and sets exit code to 5
exit(5) : prints '5' and sets exit code to 5
exit('Some message'): prints 'Some message' and sets exit code to 0
...etc. Existing scripts which use exit() to output a message would
still output the same message they currently do, so we maintain
backward compatibility. The only difference would be that exit() would
work the same way other php functions do--for instance, we expect the
same output from 'echo chr(65);' and 'echo chr("65");', right? Why
should exit be any different?
> On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote :
> > Vlad Krupin writes:
> > > Please, understand me correctly - I have nothing against exit() working
> > > in the same manner regardless of the type of the argument. I would love
> > > to see that. The problem is that (1) it already accepts a string, and
> > > has been working that way for a long time, so this can't go away, and
> > > (2) there is no other way (AFAIK) to set exit codes, and some people
> > > need that. Those are somewhat contradicting requirements, so we might
> > > have to compromise.
> > >
> > > I do have a problem with the compromise you proposed though, if I
> > > understood you correctly. You suggest using something like
> > >
> > > > exit("1boo")
> > >
> > > And having exit() parse the first digit out. That's BAD. What if
> >
> > It's not parsing anything. It's just converting to int using the well
> > documented rules of string to integer conversion which have existed in
> > the language for years. The language is pretty much impossible to use
> > without running into implicit type conversions--it's designed for
> > it. That's why the current behaviour of exit() breaks consistency.
> > Please, check out the Type Juggling section of the manual. This
> > shouldq not a special case, but it currently is treated as one. It
> > should behave the way the rest of the language behaves.
> >
> > > someone already uses exit("123, 456 servers are unavailable"); or
> > > something similar. How should we parse something like that? Chances
> >
> > Again, we don't. We let the language deal with it like it does every
> > other string->integer conversion.
> >
> > > of that are slim, but just as good as Zeev's argument where he says
> > > that there are scripts out there that rely on the current
> > > implementation of exit(), e.g. one of his own. Jamming two values
> > > into a storage space designed for a single value (a string) is bad
> > > :(
> >
> > In the case you gave, the only difference the user would notice
> > would be that the exit status of the script would be 123 instead of
> > 0. It would still print out the '123, 456 servers are unavailable'.
> >
> > > Vlad
> > >
> > >
> > >
> > > Lars Torben Wilson wrote:
> > >
> > > >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]
>
> --
> Please always Cc to me when replying to me on the lists.
>
> --
> 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]
>
--
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]
