[EMAIL PROTECTED] writes:
> On Thu, 20 Dec 2001, Zeev Suraski wrote:
>
> > This patch is fine with me, but as it would still print out the error
> > message, I think it's not fine with some other people...
>
> This solves nothing IMO. The problem is that exit (5) displays '5', and
> that must be fixed.
>
> Derick
This does solve a problem, just not that one. :) I did actually
address that one as well in my message, with the suggestion of an
optional second parameter to suppress the output. Something like:
void exit($status[, $suppress_output = false])
Existing scripts would behave as they always have but coders would
have the option to not have any output generated. My personal
suggestion would be to do this, actually:
void exit($status[, $suppress_output = true])
void die($status[, $suppress_output = false])
...but that first one would reintroduce the BC problem. :)
Anyway, the whole output/not output thing isn't that important to me
personally; I was more concerned about the inconsistency in the
argument usage. At least with that patch it would be
language-consistent, even if one doesn't like the output.
> >
> > At 16:29 20/12/2001, Lars Torben Wilson wrote:
> > >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]
> >
>
>
> --
> 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]
