NYCPHP Meetup

[Andrew Kamm]

> You can keep it static, but the child class must manually modify the
> values as desired rather than setting the property in the child.
> 
> class a {
>     public static $aa = 'original';
>     public static function e() {
>         echo self::$aa . "<br/>\n";
>     }
> }
> 
> class b extends a {
>     public function m() {
>         self::$aa = 'modified';
>     }
> }
> 
> b::m();
> b::e();
> 
> 
> --Dan


That's basically the problem I'm having -- your example redeclares a new
function in the child class. I would like to declare all of my functions in
the parent class, then allow the child classes to inherit them and have any
static references refer to the static vars in the children and not the
parent. I've tried using constants and get the same results.

I guess it seems logical to me that static self:: variables would work like
how $this-> variables work. When you have a parent class and the child class
inherits the functions, an instantiated child object will use it's own
variables when it is faced with an inherited function that includes
'$this->' (it's not going to fail or look to the parent class for a value).

I'm trying to avoid having to re-write the functions in each child class
because it kind of defeats the purpose of even having a parent class. I
assume I'm missing something, but it seems like a pretty big omission from
PHP --- this really limits the usefulness of class inheritance if I have to
paste code into several child classes.

Basically:

****************************
class a {
    
    //declare parents var
    public static $var = 'original';
    
    //function that will be used in parent and child
    public static function e() {
        echo self::$var . "<br/>\n";
    }
}


class b extends a {
    //declare child's version of the static $var
    public static $var = 'modified';
}

b::e(); //outputs 'original'
****************************

If anyone can give me an example of how this is advantageous and not a bug,
I'd greatly appreciate it. I'd much prefer to see a positive side to this
(especially after hours of trying to work around it), and I really can't.

Is there a better way to handle situations like this? I'm open to
suggestions. I've got a work around, but I'd rather work in a 'best
practices' pattern than just hack around the limitations of the language (if
it is indeed a limitation and not a feature that I am misunderstanding).

If it's not advantageous, any chance it'll be ditched in V.6? Word on the
street is it's not very popular.

thanks again-

-- 
Andrew Kamm