Zeev Suraski writes: > At 15:18 20/12/2001, Yasuo Ohgaki wrote: > >Nobody should complain about BC changes if changes are notified > >early enough and there is alternative way to do the same thing. > >IMHO. (This has been done for some features such as track vars ;) > > That's a very impractical statement in my opinion... Breaking > compatibility hurts (almost) regardless of when you announce you're going > to break it. Users would still have to go over their code and fix it. > > What I *really* fail to understand is the gain we get by modifying exit()'s > behavior, as opposed to adding a new function or adding a new $silent > argument. Giving a WFF to several people? Consistency with other > languages that have nothing to do with the Web environment (which is why we > got so little complaints about this over *5* years)?
What would the problem be with the attached patch (against PHP 4.1.0rc3)? This patch meets the following criteria: o Backward compatibility is maintained, since strings passed to exit() will still be output. BC will only break in those instances where something depends on the fact that PHP will not set the exit code when exiting with a string--very unlikely. This should keep the BC people happy and not introduce any new surprises. o No new functions need to be created, and no new arguments need to be added to exit(). This should keep the No New Functions or Arguments For Small Functionalities people happy. o exit() will now behave like other PHP functions wrt its argument type. Whereas a PHP programmer expects the calls somefunc('2') and somefunc(2) to behave identically, exit() breaks this mould. This patch rectifies that, so that exit('2') and exit(2) will now behave the same. Again, the only time BC is broken is in cases where something depends on i.e. exit('2') outputting '0'--which is likely to be *very* rare since it doesn't make any sense. Of course, the criterium which this patch does not fulfil is that of killing the output from exit(), which would break BC. However, it would still be possible to add an option second argument to exit() which would suppress this output, but be off by default. > I see this as very similar to the case sensitivity issue, even though this > is obviously on a much smaller scale. It's possibly a bad decision that > was made 5 years ago, but it was made all the same. Since it does *not* > have far-reaching negative implications, it shouldn't be changed. > > Zeev The current behaviour may not be earthshatteringly bad, but it does break language consistency and so introduces a higher memory load on the user (gotta remember that everything works the same 'cept exit()). It also tends to keep some people (OK, at least me) from doing much non-web scripting in PHP since it's a fairly fundamental bit of functionality which is something of a bother to work around. Not a major bother, but enough. My point is this: we don't break, lose, or complicate anything with this patch, and it makes the language more consistent and generally usable. Just my $0.02 for the night. Torben --- zend_execute.bak Wed Dec 19 16:19:44 2001 +++ zend_execute.c Wed Dec 19 16:37:29 2001 @@ -2379,11 +2379,16 @@ case ZEND_EXIT: if (opline->op1.op_type != IS_UNUSED) { zval *ptr; + zval exit_code; ptr = get_zval_ptr(&opline->op1, Ts, &EG(free_op1), BP_VAR_R); - if (Z_TYPE_P(ptr) == IS_LONG) { - EG(exit_status) = Z_LVAL_P(ptr); - } + + exit_code = *ptr; + zval_copy_ctor(&exit_code); + convert_to_long(&exit_code); + + EG(exit_status) = Z_LVAL_P(&exit_code); + zend_print_variable(ptr); FREE_OP(&opline->op1, EG(free_op1)); } -- 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]