The Non-Virtual Interface idiom in D

[Michel Fortin]

On 2009-09-27 09:53:12 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

>> Then your examples should have shown this instead.
> 
> Herb's article has them!

>From what I read, Herb's article is focussing on making classes ABI 
less fragile by removing virtual functions from public view and forcing 
users to call them behind a non-virtual functions. My take on this is 
that it's useful, but unintuitive.

There is one example where he separates a task into multiple virtual 
functions called apparently in sequence from non-virtual one. That's a 
fine concept, but putting this into something called "interface" seems 
dubious to me as it looks more like an implementation detail than an 
interface.

Still, having a way to write a default implementation for a function in 
an interface seems useful to me in some situations, but not in those 
illustrated the article you pointed to.


>> I fully support having a way to specify a default implementation for a 
>> function in an interface. It might get handy for a few things (like 
>> implementing the delegate pattern you see everywhere in Cocoa). But 
>> it's a bad replacement for contracts.
> 
> Walter has implemented contract inheritance, and we hope to be able to 
> have contracts on interfaces in too. The former is a nice expected 
> feature; the latter could convince DbC skeptics to start using it.

That's really great! :-)


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/