Acces to private property about pthreads

[krakjoe]

Ok, thought I'd let you know I've seen the report, will have a look in the next few days.

[krakjoe]

I am still looking at this, we have a couple of bugs that are related to the same things and I'm trying to find a common solution ...

[antoniobermuda]

Thank you good luck :)

[krakjoe]

Well I've cleaned right up and the bug is still there ... I'll keep looking ...

It's not really of the highest priority, on account of notices shouldn't be getting displayed in production ... I know it shouldn't be there, but it's not a show stopping thing ...

[bixuehujin]

Also the same problem with static private property.

[krakjoe]

Ok, thanks for the heads up ...

I have some more new ideas, I'll keep looking ...

[shoghicp]

Shouldn't you define it first before trying to access it?

[antoniobermuda]

Why?

[krakjoe]

@shoghicp, it's not that simple, see the var is actually defined, but it is unset. if you run the same code outside of pthreads or change the access modifier you will see it generate no error ... I have not got to the bottom of this yet .... I hadn't forgotten, how could I ... thorn in my side ....

[krakjoe]

Just to keep you all updated, I come back to this every time I have the time and energy to get involved in those parts of pthreads where I think the bug originates ... needless to say I haven't yet found the solution :(

The official workaround for now is just to declare members as public and everything will work as expected, which is crappy I know, I do hope to find out what's doing it, it's got to be something relatively simple that I am overlooking ...

[circuitbomb]

If you ensure the child class calls the parents method it doesn't output the Notice. PHP docs state that child classes overriding parent definitions of a method won't subsequently call the method; the extended class has to.

"Note: Parent constructors are not called implicitly if the child class defines a constructor. In order to run a parent constructor, a call to parent::__construct() within the child constructor is required. If the child does not define a constructor then it may be inherited from the parent class just like a normal class method (if it was not declared as private)."

and

"When an extending class overrides the parents definition of a method, PHP will not call the parent's method. It's up to the extended class on whether or not the parent's method is called. This also applies to Constructors and Destructors, Overloading, and Magic method definitions."

So:

<?php
class parentClass {

    private $var;

    public function __construct() {

        echo $this->var;

    }

}

class childClass extends parentClass {
        public function __construct(){
                parent::__construct();
        }
}

class clientThread extends Thread {

    public function run() {

        $objChild = new childClass();

    }

}


$objClientThread = new clientThread();
$objClientThread->start();
?>

Works.

[krakjoe]

Run it outside of pthreads ...

<?php
class parentClass {

    private $var;

    public function __construct() {

        echo $this->var;

    }

}

class childClass extends parentClass {

}
$class = new childClass();

[circuitbomb]

I would expect PHP to output an error here, mainly because $var is private and implicitly called through the parent construct by invoking the child - but I see where your coming from because the child class doesn't explicitly try to invoke the var. This is brainstaking.

In either test case changing the var scope to protected doesn't generate the notice.

Could it be a PHP bug?

edit: Though I am tired so if I sound a** backwards there is a good chance I am.

[krakjoe]

It feels internal to pthreads ... A side effect of the voodoo being conducted here ... I'll get it eventually most likely ... With public modifier no notice from original example either ... I've spent many hours on it ... Lastly grrrrr

[circuitbomb]

Well at least there is some talk and work-around-ish chatter here. There are PHP bugs going back years that haven't been fixed so as long as its not completely breaking faces I wouldn't be to worried about :D

[krakjoe]

I have included a test for this one based on the original broken example ... pretty glad to say goodbye to it :)