Re: New zend_compile.c to solve all of the duplicate function problems
| From: | Stanislav Malyshev | Date: | Fri, 19 Oct 2001 07:45:25 +0000 |
| Subject: | Re: New zend_compile.c to solve all of the duplicate function problems | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-68302@lists.php.net to get a copy of this message | ||
DB>> where people were attempting to actually redefine a function
DB>> name. Brian's patch allows the compiler to encounter the same
DB>> function in the same file on the same line and only give a
DB>> notice instead of a fatal error. It's not the most elegant
Which is not backward-compatible with how PHP behaved until then. That's
what I was saying.
DB>> solution, but then again, we have no #ifdef and #ifndef as you C
DB>> coders do to allow us to properly create function libraries.
A lot of languages don't have ifdefs (actually, most of them). A lot of
languages do not allow to redefine functions. Still each of these
languages allows to create code libraries. Obviously, your implied
argument that this is needed to implement libraries is wrong.
DB>> If/else could be used to achieve similar results, but from what
DB>> I understand, only under a serious performance penalty. Which,
DB>> BTW, is very unacceptable.
Actually, even now it can be done properly, given:
1. Reusable code (variables) and definition code (function) reside in
different files, just like you would do it in C
2. include and include_once is used properly
It would be much better if PHP could have a concept of a library package,
which would solve a lot of "did I already have this package, and if not,
how I import it properly?" questions. Making quick hacks to bend the
language into compliance with some hacky way to solve the problem won't do
any good in the long run, only bring more problems.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115