Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759edit=1 ID: 61759 Comment by: contact at jubianchi dot fr Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: I agree with Johannes about consistency. The severity is not really is not very high and this use case can easily be handled at a useland level. As long as this behavior is not fixed I think a warning on the doc shoudl be enough, even if I'd like to see it fixed (but as I said, it's not a big deal at the moment). BTW, thanks for you work Julien :) Previous Comments: [2013-08-27 10:08:00] johan...@php.net Technically we could, but it adds some inconsistency if one place allows this but others not and that should be avoided. [2013-08-27 09:46:53] jpa...@php.net The following patch has been added/updated: Patch Name: fix-class_alias Revision: 1377596813 URL: https://bugs.php.net/patch-display.php?bug=61759patch=fix-class_aliasrevision=1377596813 [2013-08-27 09:45:12] jpa...@php.net Johannes: I agree, but we could start by patching this bug report right? I got a patch here : https://github.com/jpauli/php- src/compare/class_alias_registration_fix [2013-08-26 18:32:26] johan...@php.net Note: The bug report is too restrictive. A proper patch would have to work on all places where classnames come from string context. This at first means verifying that all places go via zend_lookup_class() and related functions, not EG(class_table) / CG(class_table) [2013-08-26 18:13:08] contact at jubianchi dot fr I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6). I wrote a simple test case, here it is : Test script: --- namespace jubianchi\Alias { class A {} var_dump(class_alias('\\jubianchi\\Alias\\A', 'C')); $reflector = new \ReflectionClass('C'); var_dump($reflector-getName()); var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B')); try { $reflector = new \ReflectionClass('\\jubianchi\\Alias\\B'); var_dump($reflector-getName()); } catch(\Exception $e) { var_dump(get_class($e) . ': ' . $e-getMessage()); } var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B')); $reflector = new \ReflectionClass('\\jubianchi\\Alias\\B'); var_dump($reflector-getName()); } Expected result: bool(true) string(17) jubianchi\Alias\A bool(true) string(17) jubianchi\Alias\A bool(true) string(17) jubianchi\Alias\A Or: bool(true) string(17) jubianchi\Alias\A bool(false) string(60) ReflectionException: Class \jubianchi\Alias\B does not exist bool(true) string(17) jubianchi\Alias\A Actual result: bool(true) string(1) A bool(true) string(17) jubianchi\Alias\A bool(true) string(60) ReflectionException: Class \jubianchi\Alias\B does not exist bool(true) string(17) jubianchi\Alias\A As you can see, class_alias returns bool(true) as if everything went fine, so we expect the alias to be available but a reflection on the latter throws an exception. I think class_alias should be able to handle the leading backslashes or return bool(false) if it can't. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61759 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759edit=1 ID: 61759 Comment by: contact at jubianchi dot fr Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: Also agree with the fact that the leading backslashes are redundant but the point is that class_alias returns a value saying all went fine (bool(true)) when the alias is not reachable after the call. Previous Comments: [2013-08-27 12:10:10] ni...@php.net I'm not convinced that allowing a leading \ is something we should strive towards. The \ is unnecessary and redundant (as string names are always fully qualified). I'd rather allow only the canonical form. [2013-08-27 12:04:43] jpa...@php.net Yep, let's start finding all places where classes as strings can be used, and patch them all to use zend_lookup_class(). There shouldn't be tons of them AFAIR. [2013-08-27 10:19:53] contact at jubianchi dot fr I agree with Johannes about consistency. The severity is not really is not very high and this use case can easily be handled at a useland level. As long as this behavior is not fixed I think a warning on the doc shoudl be enough, even if I'd like to see it fixed (but as I said, it's not a big deal at the moment). BTW, thanks for you work Julien :) [2013-08-27 10:08:00] johan...@php.net Technically we could, but it adds some inconsistency if one place allows this but others not and that should be avoided. [2013-08-27 09:46:53] jpa...@php.net The following patch has been added/updated: Patch Name: fix-class_alias Revision: 1377596813 URL: https://bugs.php.net/patch-display.php?bug=61759patch=fix-class_aliasrevision=1377596813 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61759 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759edit=1 ID: 61759 Comment by: contact at jubianchi dot fr Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6). I wrote a simple test case, here it is : Test script: --- namespace jubianchi\Alias { class A {} var_dump(class_alias('\\jubianchi\\Alias\\A', 'C')); $reflector = new \ReflectionClass('C'); var_dump($reflector-getName()); var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B')); try { $reflector = new \ReflectionClass('\\jubianchi\\Alias\\B'); var_dump($reflector-getName()); } catch(\Exception $e) { var_dump(get_class($e) . ': ' . $e-getMessage()); } var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B')); $reflector = new \ReflectionClass('\\jubianchi\\Alias\\B'); var_dump($reflector-getName()); } Expected result: bool(true) string(17) jubianchi\Alias\A bool(true) string(17) jubianchi\Alias\A bool(true) string(17) jubianchi\Alias\A Or: bool(true) string(17) jubianchi\Alias\A bool(false) string(60) ReflectionException: Class \jubianchi\Alias\B does not exist bool(true) string(17) jubianchi\Alias\A Actual result: bool(true) string(1) A bool(true) string(17) jubianchi\Alias\A bool(true) string(60) ReflectionException: Class \jubianchi\Alias\B does not exist bool(true) string(17) jubianchi\Alias\A As you can see, class_alias returns bool(true) as if everything went fine, so we expect the alias to be available but a reflection on the latter throws an exception. I think class_alias should be able to handle the leading backslashes or return bool(false) if it can't. Previous Comments: [2012-04-18 06:11:21] ahar...@php.net Description: Aliasing namespaced classes currently expects that class names will be given in the same form as the ZE uses internally; ie without a leading backslash. Since that's inconsistent with the absolute form in PHP, it would be good if class_alias() could also ignore a leading backslash. Test script: --- ?php namespace A; class C { function foo() { echo 42\n; } } namespace B; class_alias('\A\C', '\B\C'); $c = new C; $c-foo(); Expected result: 42 Actual result: -- Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759edit=1
[PHP-BUG] Bug #52976 [NEW]: DOMAttribute 'disabled' can't have a value
From: Operating system: OS X 10.6.4 PHP version: 5.3.3 Package: DOM XML related Bug Type: Bug Bug description:DOMAttribute 'disabled' can't have a value Description: It seems like there's a bug when trying to set a value to the 'disabled' attribute using the DOMElement::setAttribute($name, $value) function. Test script: --- ?php $dom = new DOMDocument(); $a = $dom - createElement('input'); $a - setAttribute('disabled', 'ok'); $dom - appendChild($a); $b = $dom - createElement('input'); $b - setAttribute('disabled', 'somethingelse'); $dom - appendChild($b); $c = $dom - createElement('input'); $c - setAttribute('required', 'required'); $dom - appendChild($c); echo $dom -saveHTML(); ? Expected result: input disabled=disabledinput disabled=somethingelseinput required=required Actual result: -- input disabledinput disabledinput required=required -- Edit bug report at http://bugs.php.net/bug.php?id=52976edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52976r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52976r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52976r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52976r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52976r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52976r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52976r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52976r=needscript Try newer version: http://bugs.php.net/fix.php?id=52976r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52976r=support Expected behavior: http://bugs.php.net/fix.php?id=52976r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52976r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52976r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52976r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52976r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52976r=dst IIS Stability: http://bugs.php.net/fix.php?id=52976r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52976r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52976r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52976r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52976r=mysqlcfg