Re: [PHP-DEV] Using child classes/interfaces as desired type hints
On Thu, Oct 7, 2010 at 7:56 AM, Nathan Nobbe quickshif...@gmail.com wrote: Hi, Probly rehashing an old conversation here, but I'm wondering why the following isn't supported ?php 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=10777490481r=1w=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, -nathan It was discussed recently: http://marc.info/?l=php-internalsm=128220433328115w=2 Tyrael
Re: [PHP-DEV] Using child classes/interfaces as desired type hints
On 07/Oct/10 8:56 AM, Nathan Nobbe wrote: Hi, Probly rehashing an old conversation here, but I'm wondering why the following isn't supported ?php abstract class AbstractServer {} class ConcreteServer extends AbstractServer {} abstract class AbstractClient { abstract function doStuff(AbstractServer $o); } class ConcreteClient extends AbstractClient { function doStuff(ConcreteServer $o) {} } ? Here's the problem: class ConcreteServer2 extends AbstractServer {} Now, ConcreteClient can't receive an instance of ConcreteServer2 as an argument, although the initial hint, AbstractServer would have allowed it. -- IonuČ› G. Stan | http://igstan.ro -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using child classes/interfaces as desired type hints
On Thu, October 7, 2010 12:56 am, Nathan Nobbe wrote: ?php 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=10777490481r=1w=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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using child classes/interfaces as desired type hints
Hi, Probly rehashing an old conversation here, but I'm wondering why the following isn't supported ?php 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=10777490481r=1w=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, -nathan