Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35367 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65090 invoked by uid 1010); 11 Feb 2008 11:39:17 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 65075 invoked from network); 11 Feb 2008 11:39:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Feb 2008 11:39:17 -0000 X-Host-Fingerprint: 83.135.69.21 i53874515.versanet.de Received: from [83.135.69.21] ([83.135.69.21:20344] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 88/F9-64922-3E330B74 for ; Mon, 11 Feb 2008 06:39:17 -0500 Message-ID: <88.F9.64922.3E330B74@pb1.pair.com> To: internals@lists.php.net Date: Mon, 11 Feb 2008 12:39:06 +0100 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 References: <5F.AA.64922.495BFA74@pb1.pair.com> <345fd5cd0802110319n375a2824sd0194b2486f226e2@mail.gmail.com> In-Reply-To: <345fd5cd0802110319n375a2824sd0194b2486f226e2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 83.135.69.21 Subject: Re: [PHP-DEV] Problems with LSB From: sebastian.deutsch@9elements.com (Sebastian Deutsch) Hello, care... my case is slightly different. I was aware of that problem, but in my case I call B::foo() from the main scope - it behaves right - when I call it within the scope of C (same call) it behaves different. This is different as described in the bug. The same call should have the same output, not depending of the scope where I call it. Sebastian Lokrain schrieb: > Hello, Sebastian > > This seems to be a known bug http://bugs.php.net/bug.php?id=43408 and in > fact already assigned. > > Fallbacks occur in static/self calls, as static/self resolve to "foo" >> and it returns foo as expected. >> >> However, when you do a parent::demo() you actually call bar::demo(), >> which is currently understood as a "fully qualified call": the caller is >> not passed. >> >> There are plans to allow explicit parent call to pass the caller, but >> this is *still under discussion*. >> >> >