On 2005 Jan 12, at 20:39, Phillip J. Eby wrote:
...
>> > it's difficult because intuitively an interface defines a
>> *requirement*, so
>> > it seems logical to inherit from an interface in order to add
>> requirements!
>>
>> Yes... I would fall into this trap as well until I'd been burned a
>> few times.
>
> It's burned me more than just a few times, and I *still* sometimes
> make it if I'm not paying attention. It's just too easy to make the
> mistake. So, I'm actually open to considering dropping interface
> inheritance.
What about accepting Microsoft's QueryInterface precedent for this? I
know that "MS" is a dirty word to many, but I did like much of what
they did in COM, personally. The QI precedent would be: you can
inherit interface from interface, but that does NOT intrinsically imply
substitutability -- it just means the inheriting interface has all the
methods of the one being subclassed, with the same signatures, without
having to do a nasty copy-and-paste. Of course, one presumably could
use NO_ADAPTER_NEEDED to easily (but explicitly: that makes a
difference!) implement the common case in which the inheriting
interface DOES want to assert that it's perfectly / losslessly / etc
substitutable for the one being inherited.
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4