Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:23734 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1976 invoked by uid 1010); 27 May 2006 22:05:32 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 1961 invoked from network); 27 May 2006 22:05:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 May 2006 22:05:32 -0000 X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6 Received: from ([81.169.182.136:38192] helo=strato.aixcept.de) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 65/D5-17316-B2DC8744 for ; Sat, 27 May 2006 18:05:31 -0400 Received: from baumbart.mbo (dslb-084-063-013-138.pools.arcor-ip.net [84.63.13.138]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by strato.aixcept.de (Postfix) with ESMTP id A686835C1DC; Sun, 28 May 2006 00:05:27 +0200 (CEST) Date: Sun, 28 May 2006 00:03:40 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <4410698096.20060528000340@marcus-boerger.de> To: Todd Ruth Cc: Andi Gutmans , Edin Kadribasic , In-Reply-To: <1148496966.19173.79.camel@notebook.local> References: <138663365.20060514205903@marcus-boerger.de> <038d01c676f8$ab9b3380$6602a8c0@foxbox> <44685D24.2000801@php.net> <1147708994.14148.23.camel@notebook.local> <16710545416.20060515202714@marcus-boerger.de> <1147721541.14148.47.camel@notebook.local> <4468DB43.1020005@emini.dk> <7.0.1.0.2.20060515194051.02b32ef8@zend.com> <1148496966.19173.79.camel@notebook.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] fatal static call in php 6.0? From: helly@php.net (Marcus Boerger) 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-- > 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