#39667 [NEW]: class extends should parse a T_VARIABLE

From: codeslinger at compsalot dot com Operating system: Any PHP version: 5.2.0 PHP Bug Type: Feature/Change Request Bug description: class extends should parse a T_VARIABLE Description: ------------ Feature Request: The construct: class foo2 extends foo1{} will only accept a T_STRING for foo1 But what is highly desired is to also accept a T_VARIABLE. class $strFoo2 extends $strFoo1{} Should be a valid construct. This would enable some very powerful techniques, such as object encapsulation and psudo-nesting. Reproduce code: --------------- //Goal: To encapsulate a multiply subclassed object class foo1{ function foo1{echo "foo1\n";} } $MyClass = "foo1"; class foo2 extends $MyClass{ function CoolExtention1{echo "Cool Extension #1\n";} } $MyClass = "foo2"; class foo3 extends $MyClass{ function TotallyCoolExt{echo "Totally Cool Ext #2\n";} } $MyClass = "foo3"; ////////////// // // The program now sees an encapsulated class // without having to know anything in advance. // and without having to be modified when changes // are made to the object. $MyObj = new $MyClass; Expected result: ---------------- /******************* It's a question of being able to isolate the dependancies I don't want to hard-code the class names because I have multiple alternative extendors for the base class. It's basically a bunch of building blocks that I assemble as needed to create a custom class, giving me a common interface but with different functional implementations. I want the consuming program to see a single encapsulated object class. Aggrate does not do inheritance. PHP5 has Great!!! tools for working with objects and functions. But Encapsulation is one area it lacks and which could easily? be added by enabling the class definition to parse T_VARIABLEs and then using the trick above. This gives you the functional equivlent of nested classes as long as you manage your references carefully. I did manage to get this working using eval, but it's an ugly hack when dealing with a class of any complexity. \$everywhere. I also have some concerns about what the eval approach may be doing to runtime performance versus what could be done at cachable compile time. ///////////////////////////////////////////////////////// Taking it to the next level...a trick nobody else can do? class $strfoo2 extends $MyClass{ function {$strfoo2}{echo "Awesome $strfoo2 class!\n";} } *******************/ Actual result: -------------- Parse error: unexpected T_VARIABLE, expecting T_STRING -- Edit bug report at http://bugs.php.net/?id=39667&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39667&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39667&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39667&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39667&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39667&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39667&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=39667&r=needscript Try newer version: http://bugs.php.net/fix.php?id=39667&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39667&r=support Expected behavior: http://bugs.php.net/fix.php?id=39667&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39667&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39667&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39667&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39667&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39667&r=dst IIS Stability: http://bugs.php.net/fix.php?id=39667&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39667&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39667&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39667&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=39667&r=mysqlcfg