On 2009-09-27 09:53:12 -0400, Andrei Alexandrescu
<seewebsiteforem...@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.for...@michelf.com
http://michelf.com/
