Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.2.16

Bug #3197 Incorrect case in a is_a
Submitted: 2005-01-14 02:47 UTC
From: php at mithis dot com Assigned:
Status: Bogus Package: HTML_QuickForm
PHP Version: Irrelevant OS: Linux
Roadmaps: (Not assigned)    
Subscription  


 [2005-01-14 02:47 UTC] php at mithis dot com
Description: ------------ The code in RuleRegistry.php at line 217 reads if (is_a($element, 'html_quickform_group')) { it should read if (is_a($element, 'HTML_QuickForm_group')) { otherwise it will always evaulate to false. Reproduce code: --------------- Patch: --- RuleRegistry.php.orig 2005-01-14 12:53:53.000000000 +1030 +++ RuleRegistry.php 2005-01-14 12:54:00.000000000 +1030 @@ -214,7 +214,7 @@ { $jsIndex = isset($index)? '[' . $index . ']': ''; $tmp_reset = $reset? " var field = frm.elements['$elementName'];\n": ''; - if (is_a($element, 'html_quickform_group')) { + if (is_a($element, 'HTML_QuickForm_group')) { $value = " var {$elementName}Elements = '::"; for ($i = 0, $count = count($element->_elements); $i < $count; $i++) { $value .= $element->getElementName($i) . '::';

Comments

 [2005-01-14 07:01 UTC] avb
Bullshit.
 [2005-01-15 02:20 UTC] php at mithis dot com
This occurs in php5, specially when using the __autoload option. PHP5 doesn't find a class called 'html_quickform_group' hence tries to use __autoload to find it. Use the following code to produce it. <?php function __autoload($classname) { print "Trying to find $classname"; } $form = new HTML_QuickForm('context', 'get'); $form->addElement('text', 'textfield', 'Some text'); $form->addRule('text', 'Some text is required.', 'required', '', 'client'); $fomr->display(); It will print out "Trying to find html_quickform_group" then the form. If you fix the case in RuleRegistry.php it will only output the form.
 [2005-01-15 08:29 UTC] avb
Fix your __autoload() method to ignore HTML_QuickForm_* classes. Besides PHP documentation [1] only states that __autoload() should be called when you actually try to instantiate an undefined class. So this may be a bug in PHP itself, consider filing a bug report. [1] http://www.php.net/manual/en/language.oop5.autoload.php
 [2005-01-15 09:28 UTC] php at mithis dot com
You may define an __autoload function which is automatically called in case you are trying to USE a class which hasn't been defined yet. By calling this function the scripting engine is given a last chance to load the class before PHP fails with an error. You are using a class when doing a is_a (to check that the current object is an instance of the class), hence __autoload is called. From the above it is clear that if __autoload is being called a class CAN NOT be found. What is the point of not fixing this, it's a simple one line change and doesn't not change the behaviour in any other instance?
 [2005-01-21 19:29 UTC] avb
The point is simple: I won't change this because I do not consider this a bug in QuickForm. QuickForm works as expected on PHP5, the error lies within *your* __autoload() method, and that is the method that should be fixed.
 [2005-07-26 16:27 UTC] scott at crisscott dot com
Please reconsider fixing this bug. It is a bug within HTML_QuickForm and not with PHP itself or the implementation of __autoload. This implementation of __autoload: function __autoload($class) { include_once str_replace('_', '/', $class) . '.php'; } Should work for any PEAR class that follows the PEAR naming conventions. Even though HTML_QuickForm_group doesn't follow the PEAR naming conventions, proper capitalization would allow the __autoload implementation to work properly. It is unreasonable to expect every developer that uses HTML_QuickForm and PHP5 to add a special HTML_QuickForm clause to their __autoload function. A quick grep for is_a in my PEAR directory shows that Mail, Log, Net_SMTO, Console_Getargs, Console_Getopt, PHP_Beautifier, and PEAR all use is_a. Should I put in special statements to ignore all of their autoloads as well?
 [2005-07-26 18:17 UTC] justinpatrin
avb: I don't see what your issue is here. If it doesn't break PHP4 then change the line. __autoload() *should not be called* if a class is already defined. Either fix your code or explain in detail what the bug in PHP is so that it can be fixed.
 [2005-07-26 18:26 UTC] avb
The bug is neither in QuickForm, nor (probably) in PHP --- there was no autoload in PHP4, so no BC break in PHP5. The bug is within the __autoload() code. The error is raised within __autoload() function, not in QuickForm. __autoload() function can and should be fixed to not cause the error. QuickForm has its fair share of bugs, it will only contain workarounds for problems in PHP language itself. This is not a problem in PHP language, this is problem in __autoload() function some lazy guy is writing and not willing to fix. Whining will not help.
 [2005-07-26 18:51 UTC] thesaur
The problem is the is_a implementation in php5. As Justin said, __autoload() *will not be called* if the class is defined. So the problem is clearly caused by that line. I can't understand why you're so terribly resistant to just change one line. Do you have a good reason? Else, why not just make someone happy? (Btw, if this keeps on going, this might become a QA level bug.)
 [2005-07-26 18:56 UTC] avb
I am already trembling from the thought of crossing the path of the mighty QA! For the mighty QA to have a bit more fun, I'm copying this from the pear-dev mailing list: ========== BTW, the most obvious problem with brain-dead __autoload() implementation described by Scott in the bug report is the following. Consider: some package author would like to check for PEAR errors, but save the overhead of loading PEAR.php when there is no error, so he writes: if (is_a($returnValue, 'PEAR_Error')) { ... } Now brain-dead __autoload() kicks in and immediately dies, for there is no PEAR/Error.php: PEAR_Error is defined in PEAR.php. ========== If this keeps on going, I'll consider opening a bug for PEAR package itself.
 [2005-07-26 19:42 UTC] lsmith
Well consider it a feature request then. Contrary to PHP4, PHP5 is case preserving yet case insensitive. Furthermore I do think its am implicit rule (though not as strongly enforced as it should be) that class names (especially ones that are instatiated or included by the user) match up with the file location by simply replacing the underscore with a slash. Since alot of filesystems are case sensitive its important to use the proper case in method and class names now that PHP5 can preserve this information.