|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49105 Subclass property behaviour of questionable use...
Submitted: 2009-07-30 00:42 UTC Modified: 2009-08-01 02:57 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: atrauzzi at gmail dot com Assigned:
Status: Not a bug Package: Class/Object related
PHP Version: 5.3.0 OS: Linux
Private report: No CVE-ID: None
 [2009-07-30 00:42 UTC] atrauzzi at gmail dot com
Subclass properties should be duplicated from the parent class, not passed through to the parent class.

The current behaviour is redundant and possibly misleading.  Especially with the great selection of scopes in PHP (parent::, static::, self::).

The current workaround is to dump everything into an array on the parent, keyed by subclass.  This knocks out cohesive design and restricts the potential for some fairly neat designs.

At the very least - to prevent accidental misuse - a subclass should be throwing an error when trying to access a property that doesn't exist, but does exist on a parent.
Really what should be happening though, is a child should be getting its own copy of each property defined in the parent.

Reproduce code:
abstract class Parent {
  protected static $message = "UNTOUCHED";
     public static function yeah() {
         static::$message = "YEAH";
     public static function nope() {
         static::$message = "NOPE";
     public static function lateStaticDebug() {

class Child extends Parent {

Expected result:
Parent::lateStaticDebug();  // Return "YEAH"

Child::lateStaticDebug();  // Return "NOPE"

Child::lateStaticDebug()   // Return "NOPE"

Actual result:
Parent::lateStaticDebug();  // Returns "YEAH"

Child::lateStaticDebug();  // Returns "NOPE"

Child::lateStaticDebug()   // Returns "YEAH"


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-07-30 04:26 UTC] mail at dropdev dot org
You're confusing two similar, yet different concepts, Inheritance and Extension.

Also, PHP is doing it perfect, since you actually inherit a static variable (that all point to the same memory point.)

think of this example:
abstract class MasterAlarm {

  protected static $state = "";

     public static function alert() {
         static::$state = "ALERT";

     public static function safe() {
         static::$state = "safe";

     public static function showMasterAlarmState() {

and then extend it:
class Bell extends MasterAlarm {

class Button extends MasterAlarm {
and the executing code
Light::showMasterAlarmState();   // "safe"

Button::showMasterAlarmState();  // "ALERT"
Light::showMasterAlarmState();   // "ALERT"

Light::showMasterAlarmState();   // "safe"
 [2009-07-30 10:19 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

 [2009-07-30 12:26 UTC] atrauzzi at gmail dot com
I half expected this to happen as this is how the vast majority of issues here are handled.

It would be nice if there was a process to outline *why* this behaviour shouldn't be corrected.  A more advanced review is definitely warranted here.  That is - without simply cut-and-pasting a snippet telling people to look at the documentation.

Which is obviously a stonewall tactic to reduce bug workload.

In the strictest sense, any bug will not be documented and the current behaviour is no exception to that.  I would be pleasantly surprised to see this actually mentioned in the documentation.

Consider that if one wanted to use the parent class property, they simply would have to use self:: in the parent or parent:: in the child.  Which makes it an *explicit* design, not implied limitation that has to be worked around.
At present, this definite bug requires the use of what could only be described as a workaround and I do not feel it has been properly considered.  Being able to post source code that makes use of the bug doesn't validate it.
Because of this it is an angle of functionality not considered or explicitly handled.  Instead, a design implied by accident is accepted, in spite of the fact that it is of limited use.

I'm surprised as I'm sure issues requesting late static binding were flagged "bogus" in the past.

How long will it be before this issue is re-reported again?)
 [2009-07-30 13:25 UTC] atrauzzi at gmail dot com
As an addition, the example provided by "mail at dropdev dot org" contains a bug.

He uses static:: yet ends up with a reference to MasterAlarm.  If he wanted the calls to consistently reflect MasterAlarm, he should be using self::, as the moment any subclass declares $state, the method showMasterAlarmState() breaks by way of the subclass property.
That demonstrates how the current behaviour contradicts the expectations made of late static binding and why I suggest at the very least an error should be thrown noting an undefined property.

This in itself is classic proof of how this ambiguity is resulting in people not only accepting incorrect design convention, but also advocating it because they have come to depend on it.

The whole idea of forcing a declaration of a new property in a subclass is undesirable.

I would encourage anyone reading to revisit the principles behind why somebody would want to inherit from a base class and the advantages of using self:: over static:: explicitly rather than relying on implicit behaviour that causes poor design.

At the very least, this issue deserves more than a stonewall tactic and could likely use a formal and thoughtful review.)
 [2009-08-01 02:16 UTC]
If you disagree, feel free to bring the issue up on:

And discuss it there, this bug system is not a discussion forum.
 [2009-08-01 02:57 UTC] atrauzzi at gmail dot com
Thank you!

I've begun talking with some people and taking some input on the issue.

I'll eventually mention it at internals.  I've had some people recommend making an RFC, but I'm going to hold off a few days before doing so.

That way the idea gets ironed out nicely.)
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC