I have said this all the time..as well as many others.
Try convince Zeev to fix his one script that breaks.
--Jani
On Thu, 20 Dec 2001, Markus Fischer wrote:
> 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.
>
>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]
>
>
--
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]
