On Fri, 2003-03-07 at 15:30, Wez Furlong wrote:
> It's not a bug; PHP is a case-IN-sensitive language when it comes to
> function and class names.
I understand that, and if my message implied anything differently, I
apologize. That is precisely the problem I am addressing; when storing
the function names, Zend is doing half of the job of compliance with the
requirement of case-insensitivity; when retrieving them *from within an
extension*, it falls down.
> Adding strtolower calls will only slow down the whole language.
You are of course correct, but whoever chose to make class and function
names case-insensitive effectively required that the engine does
strtolower every time a class or function name is stored and retrieved.
Although this seems like excessive overhead to me, I would never suggest
changing this aspect of the language.
I presume this is one big reason why variable names are NOT case
insensitive in PHP--the overhead involved in case-conversion the name
for every single use every single variable would be silly. Class and
function references, of course, occur far less frequently and thus I
guess the overhead was decided to be acceptable?
Anyway, enough idle speculation on my part.
So... if I'm not mistaken, the opcode ZEND_INIT_FCALL_BY_NAME is what is
being triggered when a user function is called from a PHP script.
Is this correct?
If that's right, then you can see that line 1501 (4.3.1 release) of
zend_execute.c is where the Zend is, as you say, "slowing down the whole
language" on EVERY instance of a *script-based* function call:
tmp = *function_name;
zval_copy_ctor(&tmp);
convert_to_string(&tmp);
function_name = &tmp;
HERE-> zend_str_tolower(tmp.value.str.val, tmp.value.str.len);
As I mentioned before, a similar conversion takes place for the
ZEND_NEW opcode for instantiating classes. All I am suggesting here is
that compliance with the language standard (in re case insensitivity) is
made complete for function calls *by PHP extensions*
My old friend grep tells me that in the 4.3.1 distribution there are
exactly 49 uses of call_user_function[_ex] spread between only 23 of the
88 "stock" extensions. Of course, I have no idea how many times these
calls are actually encountered in the use of these extensions, but my
point is the overhead involved cannot possibly rival the amount already
created by the zend_str_tolower() calls within zend_execute.c, which is
surely encountered far more often in everyday use of PHP.
Does what I am suggesting make sense, now?
> Using lowercase function and class names is the best solution.
I may very well change them if my employer does not object, because I
find C-style function names more aesthetically pleasing (and because
CODING_STANDARDS suggests it for PHP extensions). They are as they are
now because the code was ported from another language.
But as I have seen no warnings or admonitions about using one or more
upper case letters in a function or class name in the available
extension-writing documentation (either online, or in the book
"Programming PHP"), I would expect them to work as documented for the
PHP language in general (on, for instance, at the bottom of page 62 of
that book, First Edition, March 2002).
By spending a not inconsiderable amount of time, I have discovered both
a workaround (use all lowercase function names--there IS currently no
problem with mixed-case class names--they are zend_str_tolower()d), and
a suggested solution (attached to my previous post) to this problem.
Using a workaround will fix my problem; making a small change to Zend
will potentially and probably save other extension developers the
trouble of having to discover workaround on their own, if they are even
capable of doing so. I would like to save them that trouble.
Most sincerely,
Eric
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
