OK, I'll admit that I went of at a bit of a tangent there. But since we're here, let me refute your example: an interface named "PitchControl" would be no less ambiguous than a method named "set_pitch". We can't use the ambiguity argument to support explicitly named interfaces.

Sorry - obviously wasn't being clear. I wasn't proposing a PitchControl interface. I was just pointing out that the method name isn't enough. The method would be part of the "interfaces" of MusicalInstrument and Aircraft, which are not ambiguous.

In both cases, the interface is made explicit. Client code can be written to require an object that implements a specific interface: the interface is explicit from the client's point of view. The binding between the object and the interface is also explicit, but the direction of the dependency is different.

I think we have different definitions of "interface". To me it includes the implied contract of the class, so:

interface Aircraft {
    method set_pitch (...);
}

class Jet : isa Aircraft {
    method set_pitch (...) {...}
}
[download]

is saying a very different thing from:

class Jet {
    method set_pitch (...) {...}
}

interface FlyingThings {
    require method set_pitch (...);
}
[download]

since:

class Piano {
    method set_pitch (...) {...}
}
[download]

isn't an Aircraft, but is a FlyingThing.

Imagine you have a blob of 3rd party code that has an overly fat interface. You can't modify this code (e.g. you're not sysadmin). You want to use these blobs in you own code, which uses a much thinner version of the same interface. You want to validate your input (i.e. does the input object implement your thin interface) without modifying the source code of an object that implements the fat interface.

Dealing with code you can't alter is once case where I can see it being useful (as I briefly mentioned in another thread).

That's one way of doing it certainly. But the information that ThinInterface is a subset of ThickInterface is lost. All you are saying is that they have the same method names - not that those methods do the same "things" to the same kind of objects.

While it might be a useful hack - that's what it is. You are deliberately subverting the isa hierarchy because you can't express the relationship that you want to express directly. It's something that should be used very carefully since it subverts (in my opinion) what OO is all about.

There are also other ways of getting round the problem. For example, if you have multiple inheritance you could declare a subclass ThickThin of ThickInterface that isa ThinInterface, and use the subclass where you would have used ThickInterface objects.

    ThickInterface    ThinInterface
            \        /
            ThickThin
[download]

With perl you can do even do ghastly things like:

unshift @ThickInterface::ISA, 'ThinInterface';
[download]

to make ThickInterface a ThinInterface retrospectively :-)