#32506 [Opn->Bgs]: bug or feature? no "virtual" resolution of self::-reference

ID: 32506 Updated by: tony2001@php.net Reported By: soletan at toxa dot de -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Linux PHP Version: 5.0.3 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #30934. Previous Comments: ------------------------------------------------------------------------ [2005-03-30 17:21:50] soletan at toxa dot de Description: ------------ First of all I expect this to be an item for your "wish list" but hope it is a "bug" (lack) to be fixed. :-) Maybe you will advise me to re-design my code ... but: ... I consider OOP in PHP5 to be a very powerful advantage over PHP4 so I started to re-implement my web application library from scratch using PHP5 ... having classes wrapping data entities encouraged me to have some kind of base class with commonly used methods like getProperty(), setProperty(), createItem(), deleteItem(), listItems() etc. There are static methods like createItem() or loadItem() which take a link to DB and a ID (in case of load) and return an instance of their own class on successful return etc. Then I'd like to have a class derived from this common class with only parametrizing the base class. So, for example, there is a method returning a list of "properties" (columns in wrapped DB-table), which are considered to be read-only. This list is requested by method getProperty() in base class and will cause some requests for adjustment to be revoked by base class method getProperty() without the need to overload it in a derived class. Other methods like create and load simply need to know what table to work with and so call a method which is telling the table's name. Okay, this might be possible using object properties declared static. But then there is another part of specification that causes conflicts: Using OOP should lead to clean wrapping of data. This is why I want to have entities like "user" being wrapped. So there is a base class as drawn before, and a derivation called "user". This implements commonly used API to user accounts. Now there are opportunities to have customers plugging in their own code. One of my bad customers implement a class "bad_user" derived from "user" and make property "password" writable while it is read-only using class "user". They can do that by simply adjusting that property giving list of read-only properties. Using a method instead and then declare that method "final" in class user it is possible to make my class "user" resistant and reliable, right!? And that's why I would prefer using that way of parameterizing my base class. But: PHP 5.0.3 is working as given below and self::... is always resolving into base class instead of virtually using overloaded method in derived class instead, even when method test was invoked in scope of derived class. Is this a bug or a feature? And if it's a feature, is there a short-time opportunity to have it changed anyhow? ;-) I know there are opportunities using __get() and __set() to work with some undeclared properties. But before I start to re-uglify my code I would like to ensure that is really working. And finally I don't like to "re-uglify" as this is a hack and reduces the power of OOP in PHP5, doesn't it!? Okay, I hope this post is no riddle for you and I thank you in advance for any advise or solution. Best Regards, Thomas Urban Reproduce code: --------------- <?php class base { static function test() { echo self::read(); } protected static function read() { return "base"; } } class spec extends base { protected static function read() { return "spec"; } } spec::test(); ?> Expected result: ---------------- spec Actual result: -------------- base ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=32506&edit=1