Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33278
Return-Path: <m@digitalsandwich.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 71878 invoked by uid 1010); 19 Nov 2007 03:45:10 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 71862 invoked from network); 19 Nov 2007 03:45:09 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 19 Nov 2007 03:45:09 -0000
Authentication-Results: pb1.pair.com smtp.mail=m@digitalsandwich.com; spf=softfail; sender-id=softfail
Authentication-Results: pb1.pair.com header.from=m@digitalsandwich.com; sender-id=softfail
Received-SPF: softfail (pb1.pair.com: domain digitalsandwich.com does not designate 68.230.241.41 as permitted sender)
X-PHP-List-Original-Sender: m@digitalsandwich.com
X-Host-Fingerprint: 68.230.241.41 fed1rmmtao105.cox.net Solaris 10 (beta)
Received: from [68.230.241.41] ([68.230.241.41:63678] helo=fed1rmmtao105.cox.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id EC/CA-31009-2C601474 for <internals@lists.php.net>; Sun, 18 Nov 2007 22:45:07 -0500
Received: from fed1rmimpo03.cox.net ([70.169.32.75])
          by fed1rmmtao105.cox.net
          (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP
          id <20071119034504.IBGY22853.fed1rmmtao105.cox.net@fed1rmimpo03.cox.net>;
          Sun, 18 Nov 2007 22:45:04 -0500
Received: from [192.168.0.102] ([68.96.248.22])
	by fed1rmimpo03.cox.net with bizsmtp
	id ETl21Y00E0Vk8yk0000000; Sun, 18 Nov 2007 22:45:03 -0500
Message-ID: <47409635.9040304@digitalsandwich.com>
Date: Sun, 18 Nov 2007 19:44:53 +0000
User-Agent: Thunderbird 2.0.0.6 (X11/20071108)
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@php.net>
CC:  internals@lists.php.net, Gergely Hodicska <felho@avalon.aut.bme.hu>, 
 "Etienne Kneuss" <colder@php.net>
References: <BE.C0.09961.C9224A64@pb1.pair.com>	 <474021AD.3020902@avalon.aut.bme.hu>	 <e666c3890711180521i41139a29r7fc166dfc0d4fa6e@mail.gmail.com> <1195392958.4012.15.camel@johannes.nop>
In-Reply-To: <1195392958.4012.15.camel@johannes.nop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] late static binding php6
From: m@digitalsandwich.com (Mike Lively)

Johannes Schlüter wrote:
> Hi,
>
> and for me the current behavior feels right: The call to
> parrent::findByPk() is an independent call from the call before and
> calls an explicit class (the parent one)
>
>   
This makes no sense to me. It makes it COMPLETELY impossible to do any
form of slightly complicated inheritance and decorators go almost out
the window for statics. It's also slightly inconsistent from how
instance inheritance works.

class A
{
        public function test()
        {
                echo get_class($this)."\n";
        }
}

class B extends A
{
        public function test()
        {
                parent::test();
        }
}

$a = new A;
$b = new B;

$a->test();
$b->test();

I realize that instance calls are a completely different ball game than
static  calls but LSB was supposed to give us the same flexibility.

I would totally agree that <class name>::<static method>() should break
the caller chain, but in my opinion parent:: should just forward the
called class on. It would allow more complex forms of inheritance,
people that have the kind of OO background that this feature is intended
for I believe will easily understand what's going on. I think more often
than not if someone is going to use parent:: instinctively that they
would be intending the caller to be forwarded (ie: for decorators, also
see polymorphism?). If you REALLY wanted the parent class explicitely
called you can just use the class name.

Basically my point is that I don't believe parent:: should be considered
'fully established' to use Etienne's terminology.

-Mike Lively

> On Sun, 2007-11-18 at 14:21 +0100, "Etienne Kneuss" wrote:
>   
>> Hello,
>>
>> this very subject was already discussed in a thread months ago. Basically,
>> it's a matter of choice whether fully established calls should break the
>> resolution or not. Both ways have drawbacks. Implementing both would require
>> yet another keyword and complications.
>>
>>
>> On Nov 18, 2007 12:27 PM, Gergely Hodicska <felho@avalon.aut.bme.hu> wrote:
>>
>>     
>>> Hi!
>>>
>>>
>>> I read this thread, and I would like to ask if is there any decision
>>> about the behavior of inheritance?
>>>
>>> I wrote on my blog about late static binding
>>> (
>>> http://blog.felho.hu/what-is-new-in-php-53-part-2-late-static-binding.html
>>> ),
>>> and I came up with the following example:
>>>
>>> <?php
>>> class ActiveRecord
>>> {
>>>     public static function findByPk($id)
>>>     {
>>>         $calledClass = get_called_class();
>>>         // The magic remains...
>>>     }
>>> }
>>>
>>> class Blog extends ActiveRecord
>>> {
>>>     public static function findByPk($id)
>>>     {
>>>         // We want to log something.
>>>
>>>         // Then the parent should do the magic.
>>>         parent::findByPk($id);
>>>     }
>>> }
>>>
>>> Blog::findByPk(1);
>>> ?>
>>>
>>>
>>> In think it would be nice if I could write codes like this. But in the
>>> current snapshot the value of $calledClass is ActiveRecord.
>>>
>>>
>>> Best Regards,
>>> Felhő
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>>
>>>       
>>     
>
>