php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32506 bug or feature? no "virtual" resolution of self::-reference
Submitted: 2005-03-30 17:21 UTC Modified: 2005-03-30 18:36 UTC
From: soletan at toxa dot de Assigned:
Status: Not a bug Package: Class/Object related
PHP Version: 5.0.3 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: soletan at toxa dot de
New email:
PHP Version: OS:

 

 [2005-03-30 17:21 UTC] 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-30 18:36 UTC] tony2001@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 06:01:28 2024 UTC