Re: No more return in file-body (was: Re: [PHP-DEV] 4.0.7 when?)
| From: | Stig S. Bakken | Date: | Wed, 17 Oct 2001 17:33:24 +0000 |
| Subject: | Re: No more return in file-body (was: Re: [PHP-DEV] 4.0.7 when?) | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-68150@lists.php.net to get a copy of this message | ||
Jeroen van Wolffelaar wrote:
>
> > Edin Kadribasic wrote:
> > >
> > > > >IMHO the only really critical bug is #13616. I cannot really test the
> RC
> > > > >since the application that I use the most (SquirrelMail for example)
> do
> > > not
> > > > >work.
> > > >
> > > > This bug is really problematic, because effectively, it's not a bug.
> > > Prior
> > > > to the current CVS, PHP behaved pretty inconsistently with function
> > > > redefinitions. This caused all sorts of issues, as can be seen in bug
> > > > 9884. Sometime since 4.0.6, I changed the behavior to be consistent -
> if
> > > a
> > > > function is redefined during compile-time, it will complain, period.
> > > > Unfortunately, this obviously has a negative side effect, and a fairly
> big
> > > > one, too. Code that used to work,
> > > > if ($foo) {
> > > > return;
> > > > }
> > > > ...function definitions...
> > > >
> > > > no longer works. Instead, you have to do something like:
> > > >
> > > > if (!$foo):
> > > > ...function definitions...
> > > > endif;
> > > >
> > > > Fixing this is trivial, it means reverting the fix for bug 9884. The
> > > > question is whether we do that or not, and we need to decide about
> it...
> > >
> > > The next PHP release is going to be 4.1.0 and is already breaking
> > > compatibility in several ways. If it makes the language more consistent,
> we
> > > should IMHO keep at as it is and document this particular change in
> release
> > > notes explaining how to fix the code. The fix is simple and it should
> work
> > > with previous versions of PHP.
>
> I strongly disagree. Using return in a script in order to stop executing
> that file is used a lot by myself, and I suppose by a lot of others too.
> Currently, include()'d files behave more or less like executing a
> argument-less function (in parent scope, that is).
>
> But the main reason is that now returning a certain value from a file is now
> broken too. (i.e., let include/require return a certain value).
Nobody is suggesting that "return" from included files should stop
returning. We're talking about what happens when you "return" before a
duplicate definition.
- Stig