From:             soletan at toxa dot de
Operating system: Linux
PHP version:      5.0.3
PHP Bug Type:     Class/Object related
Bug description:  bug or feature? no "virtual" resolution of self::-reference

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 bug report at http://bugs.php.net/?id=32506&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32506&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32506&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32506&r=trysnapshot51
Fixed in CVS:                http://bugs.php.net/fix.php?id=32506&r=fixedcvs
Fixed in release:            http://bugs.php.net/fix.php?id=32506&r=alreadyfixed
Need backtrace:              http://bugs.php.net/fix.php?id=32506&r=needtrace
Need Reproduce Script:       http://bugs.php.net/fix.php?id=32506&r=needscript
Try newer version:           http://bugs.php.net/fix.php?id=32506&r=oldversion
Not developer issue:         http://bugs.php.net/fix.php?id=32506&r=support
Expected behavior:           http://bugs.php.net/fix.php?id=32506&r=notwrong
Not enough info:             
http://bugs.php.net/fix.php?id=32506&r=notenoughinfo
Submitted twice:             
http://bugs.php.net/fix.php?id=32506&r=submittedtwice
register_globals:            http://bugs.php.net/fix.php?id=32506&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32506&r=php3
Daylight Savings:            http://bugs.php.net/fix.php?id=32506&r=dst
IIS Stability:               http://bugs.php.net/fix.php?id=32506&r=isapi
Install GNU Sed:             http://bugs.php.net/fix.php?id=32506&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32506&r=float
No Zend Extensions:          http://bugs.php.net/fix.php?id=32506&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32506&r=mysqlcfg

Reply via email to