Re: Re: Bug #13616 Updated: Compiler complains about function declaration after return is called
| From: | Daniel Beckham | Date: | Wed, 17 Oct 2001 21:07:18 +0000 |
| Subject: | Re: Re: Bug #13616 Updated: Compiler complains about function declaration after return is called | ||
| References: | 1 2 3 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-68165@lists.php.net to get a copy of this message | ||
I might be wrong here, but by doing that, wouldn't that entire if / endif
block not be compiled until it's actually executed? For large function
libraries and code files, it seems that this would seriously decrease
performance.
Sorry, I don't think that I understood that last question. =) By relevant,
do you mean when 4.1.0 is released? And you mean it should stay the same as
it is now in CVS.. not prior to the bug fix?
Thanks,
Daniel
----- Original Message -----
From: "Zeev Suraski" <zeev@zend.com>
To: "Daniel Beckham" <danbeck@dealnews.com>
Cc: "php-dev" <php-dev@lists.php.net>
Sent: Wednesday, October 17, 2001 3:46 PM
Subject: Re: [PHP-DEV] Re: Bug #13616 Updated: Compiler complains about
function declaration after return is called
> You're not losing any functionality. You can still do:
>
> if (...):
> ...declerations...
> endif;
>
> That said, let's revisit this issue when it becomes relevant. For the
> upcoming version, in my opinion, the behavior should stay the same.
>
> Zeev
>
>
> At 22:42 17-10-01, Daniel Beckham wrote:
> >----- Original Message -----
> >From: "Zeev Suraski" <zeev@zend.com>
> >To: "Brian Moon" <brianm@dealnews.com>
> >Cc: <php-dev@lists.php.net>
> >Sent: Wednesday, October 17, 2001 1:18 PM
> >Subject: [PHP-DEV] Re: Bug #13616 Updated: Compiler complains about
function
> >declaration after return is called
> >
> > > I think we're all aware that this is a problematic issue. I don't
have my
> > > mind set as to what I support, but I think that breaking
PHP-source-level
> > > compatibility at 4.1.0 is probably a bad idea (we want to encourage
> > > everybody to upgrade to it, so that they start using $_GET and
> > > friends). We can revisit this issue in 4.2.0. At any rate, I suggest
> > > starting to move towards code that's compatible with this change, in
the
> > > event that we end up making it...
> >
> >
> >What do you propose that we PHP coders do then? The include_once()
solution
> >is problematic inside of functions because of the way that PHP deals with
> >globals. This isn't so much that you are breaking code... you are
removing
> >important functionality from PHP. It isn't a point of moving code
towards
> >compatibility with this change, it's the idea of possibly not being able
to
> >write modular code any longer because we aren't able to write function
> >libraries. The entire idea of include_once() is backwards to me. You
are
> >making the user of the function library responsible for not making coding
> >mistakes such as including a file twice. It should be the included
file's
> >responsibility to handle this.
> >
> >You don't even have to do that as a C coder. An included file such as
> >string.h can be included a thousand times in your code without causing
> >problems. You know there is a macro #ifdef statement at the top that
keeps
> >it from being included more than once when compiled.
> >
> >PHP developers have no such tools, and now our hack to emulate those
tools
> >has been taken away.
> >
> >Daniel
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
> For additional commands, e-mail: php-dev-help@lists.php.net
> To contact the list administrators, e-mail: php-list-admin@lists.php.net
>
>