Hello Todd,
code like this is actually exactly what i mean. It is completley broken
design, maybe not for you of course. But according to any oo guideline.
But that's a different story. The real problem is that this behavior is
based on or worked around some behavior in the engine that is sooner or
later most likely to cause severs SEGVs.
best regards
marcus
Wednesday, May 24, 2006, 8:56:06 PM, you wrote:
> In php5 this works even without an instanceof relationship.
> (I'm running 5.1.2 and this test gets a "PASS" from run-tests.php.)
> I know the following test case does not even remotely follow
> good OO design principles, but it's hard to imagine us going
> back to the drawing board with our app. Please don't break
> the following in php6 just to teach me a lesson about OO design.
> If there's a repository of "someone will complain about a BC
> break if this changes" tests, please add the following:
> --TEST--
> test that $this survives in a semi-static call
> --FILE--
> <?php
> class TheParent {
> public $x = 3;
> }
> class UglyUncle {
> function f() {
> $this->x = 5;
> }
> }
> class Child extends TheParent {
> function f() {
> UglyUncle::f();
> }
> }
> $c = new Child();
> var_dump($c->x);
> $c->f();
> var_dump($c->x);
?>>
> --EXPECT--
> int(3)
> int(5)
> Thanks,
> Todd
> On Mon, 2006-05-15 at 19:41 -0700, Andi Gutmans wrote:
>> I don't see why it has to be a fatal error. If there's an instanceof
>> relationship we can keep $this. If not, we should not pass $this
>> (which I believe we already do in PHP 5), in which case the author
>> would have to pass $this if he wants to change public properties.
>>
>> Andi
>>
>> At 12:49 PM 5/15/2006, Edin Kadribasic wrote:
>> >Todd Ruth wrote:
>> >>I don't see benefits of making semi-static fatal that make it
>> >>worth keeping those of us with large apps that depend on semi-
>> >>static from upgrading to php6.
>> >
>> >My sentiments exactly. OO purity/strictness do now work well with
>> >PHP's main strength -- its dynamicity.
>> >
>> >Edin
>> >
>> >--
>> >PHP Internals - PHP Runtime Development Mailing List
>> >To unsubscribe, visit: http://www.php.net/unsub.php
>>
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
