Re: Re: Bug #13616 Updated: Compiler complains about function declaration after return is called

From: 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 > >

« previous php.dev (#68165) next »