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]
