Hello Todd,
if you need abstract static methods that oo wise make no sense at all
but still want them because you know your stuff better than theory then
there still is a problem in the engine code we have to maintain. In case
we had late static binding already we might have solved all related
issues alredy. In the current state the behavior is likely to cause
trouble in some cases becuase the engine was not designed to support oo
misuse/wron use. It was just an oversight not to have that test on the
place - most likely on my side, since i wrote all tests and a lot of the
oo rules code. Now that we are finally working with PHP 5 and more than
1% of our users do so as well we find more and more issues.
This situation is just like the one where we had to fix reference stuff
as we found out that it indeed was causing SEGVs in certain situations.
And i want to provide such situations and i want that at nearly all
costs because i do not want to have such a situation again. For one
reason it took me like a full week of work to help Derick with a tiny
piece in debugging and i don't know how much time Derick spend on
tracking the issue down and fixing it. In short i rather drop a feature
than risking SEGVs.
Now decide for your self what is more expensive/more dangerous for you?
An unstablel PHP or a tiny feature loss?
Btw, right now you can have abstract static methods in interfaces. This
was a compromise I introduced when we found out the issue.
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
