Markus Fischer writes: > Implictely is more error prone. How so? Can you give an example?
> On Wed, Dec 19, 2001 at 04:12:02PM -0800, Lars Torben Wilson wrote : > > 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 > > -- > Please always Cc to me when replying to me on the lists. > -- 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]