Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49887 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11165 invoked from network); 8 Oct 2010 02:07:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Oct 2010 02:07:09 -0000 Authentication-Results: pb1.pair.com header.from=ceo@l-i-e.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ceo@l-i-e.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender) X-PHP-List-Original-Sender: ceo@l-i-e.com X-Host-Fingerprint: 67.139.134.202 o2.hostbaby.com FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (2) Received: from [67.139.134.202] ([67.139.134.202:1510] helo=o2.hostbaby.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6E/87-65227-ACC7EAC4 for ; Thu, 07 Oct 2010 22:07:07 -0400 Received: (qmail 47606 invoked by uid 98); 8 Oct 2010 02:07:09 -0000 Received: from localhost by o2.hostbaby.com (envelope-from , uid 1013) with qmail-scanner-2.05 ( Clear:RC:1(127.0.0.1):. Processed in 0.036998 secs); 08 Oct 2010 02:07:09 -0000 Received: from localhost (HELO www.l-i-e.com) (127.0.0.1) by localhost with SMTP; 8 Oct 2010 02:07:09 -0000 Received: from webmail (SquirrelMail authenticated user ceo@l-i-e.com) by www.l-i-e.com with HTTP; Thu, 7 Oct 2010 21:07:09 -0500 Message-ID: In-Reply-To: References: Date: Thu, 7 Oct 2010 21:07:09 -0500 To: internals@lists.php.net User-Agent: SquirrelMail/1.4.21 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [PHP-DEV] Using child classes/interfaces as desired type hints From: ceo@l-i-e.com ("Richard Lynch") On Thu, October 7, 2010 12:56 am, Nathan Nobbe wrote: > abstract class AbstractServer {} > class ConcreteServer extends AbstractServer {} > > abstract class AbstractClient { > abstract function doStuff(AbstractServer $o); > } > > class ConcreteClient extends AbstractClient { > function doStuff(ConcreteServer $o) {} > } > ?> > > This results in a fatal > Fatal error: Declaration of ConcreteClient::doStuff() must be > compatible > with that of AbstractClient::doStuff() in > /Users/quickshiftin/gitRepos/timberline/php-api-v15-client/testOverride.php > on line 11 > > I was reading a few posts from way back when > > http://marc.info/?t=107774904800001&r=1&w=2 > > yet still find myself wondering. I think it can be said here that if > there's a contract defined by AbstractClient::doStuff, that same > contract is > honored by ConcreteClient::doStuff. I also think changing the > language to > support this notion wouldn't raise BC issues for the most part (at > all?) > since at the moment you're forced to move to the lowest common > denominator > in the tree, in this case > > class ConcreteClient extends AbstractClient { > function doStuff(AbstractServer $o) {} > } > > your feedback appreciated, I can see why you think it "should" work, but have you considered all the possible combinations of children/parent abstract/concrete classes, and what happens when you do: class QuickMixClient extends ConcreteClient { function doStuff(AbstractServer $o) {} } class QuickMixServer extends AbstractServer { } $quickie = new QuickMixServer; $client = new QuickMixCilent; $client->doStuff($quickie); Kosher? Or not? It's kosher for the QuickMix doStuff, but does not satisfy the ConcreteServer requirement of ConcreteClient. So does PHP need to examine every method on every class, and then complain at compile time?... That sounds painful to me... . . . -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE