Fragile ABI

[R Grocott]

> And yet that is what DirectX and WinRT are all about.

DirectX, yes: it's a good example of an OO library with a purely 
interface-based API. The only DirectX plugin architecture I can 
bring to mind, though (DirectShow filters), actually uses C++ 
classes (such as CSource) to hide a lot of the underlying 
complexity. I get the impression that wouldn't be necessary if 
interface-based plugins were as simple to create as 
inheritance-based ones.

Likewise, WinRT actually hides a huge amount of complexity inside 
its language bindings. Inheriting from a WinRT object using only 
the underlying COM interfaces involves a lot of hassle, and is a 
prime example of what I'm talking about. See here:

http://www.interact-sw.co.uk/iangblog/2011/09/25/native-winrt-inheritance


> Your GUI toolkit just needs to expose interfaces for the 
> different
> types of events it is required to handle, and you give via API 
> calls
> objects whose instances implement said interfaces.
>
> To avoid too much code rewrite, some component systems, COM 
> included,
> support a form of delegation where you can implement just a 
> part of the
> interface, while delegating the remaining calls to a contained 
> object.

That sounds clean in theory - but so does Pimpl, and I know from 
experience that Pimpl tends to make a horrible mess out of any 
codebase. It doesn't help that, as far as I know, COM is 
Windows-only, and D doesn't natively support the 
method-defaulting system you described.

In practice, I think that proper interoperability w/r/t classes 
and inheritance will tend be cleaner than coding strictly against 
an interface. This can be demonstrated by choosing any base-class 
derived-class pair, from any OO codebase, and attempting to 
rewrite that parent-child relationship as a server-client one.