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:
<?php
abstract class MasterAlarm {

  protected static $state = "";

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

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

     public static function showMasterAlarmState() {
         return(static::$state);
     }

}
?>
and then extend it:
<?php
class Bell extends MasterAlarm {
}

class Button extends MasterAlarm {
}
?>
and the executing code
<?php
Light::safe();
Light::showMasterAlarmState();   // "safe"

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

Button::safe();
Light::showMasterAlarmState();   // "safe"
?>

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

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?)

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.)

If you disagree, feel free to bring the issue up on:

  internals@lists.php.net

And discuss it there, this bug system is not a discussion forum.

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.)