Hi! On 9/19/11 7:26 AM, Anthony Ferrara wrote:
that point, why even bother with interfaces? The interface defines what should be accepted, and any method that implements it should accept exactly that (no more, no less, no different). Otherwise
Here you lost me. Why exactly you can not accept more? If you implement some interface, and fulfill all obligations about this interface, why can not you also accept more than this interface requires? This is certainly not the current practice - but even in theory, why would that be a requirement? LSP certainly does not require that - otherwise it would also say "any property that is not true for q(x) should also be not true for q(y)" - which btw would severely reduce what you could do in OO.
you'll violate the contract and couple to the implementation instead of the interface. This causes the checked polymorphic ability of the interface to go out the window. The result is that the interface becomes completely useless. So, in order for interfaces to be useful, they should include the exact arguments in order and in type, and the runtime (PHP) should enforce that (which it does).
I do not see why this would be true. You use interface for the protocol it defines, and it's useful for that, but you can also use extended protocol when you know particular implementation provides extended features. Yes, that would mean that this specific code would not work with all implementations of the base protocol - but that's exactly what you want, have guaranteed base and optional extension. Yes, that would introduce coupling - but sometimes you have no other way (think about something like PDO and having to support both base features and give access to additional DB-specific features for performance, etc.) I agree that it may be not ideal from purist point of view but practically I've seen many situations where it's required - especially when you can't really change the interface.
Having said that, I could begrudgingly (very begrudgingly) accept the case for doing this with interfaces. The problem we have however is not with interfaces but with abstracts.
That's my $0.02. I say leave it as is. The way it is working right now promotes good API design and makes difficult doing things that
Unfortunately, it does not - in fact, as you yourself noted, abstract should allow child classes to generalize, but right now not only this is not allowed, but the presence of an abstract anywhere in the hierarchy blocks generalization for the whole hierarchy. So not only you have to work around this particular problem when you use abstract classes - you have to work around the case where somebody refactored base classes you relied on and introduced abstract signature there - and now your perfectly good and working generalization produces fatal errors!
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
