A long discussion on the utility of interfaces has taken place on the
announce newsgroup following my announcement of dcollections for D2.
Dcollections supports interfaces peripherally. Meaning the types in
dcollections are essentially concrete classes with interfaces tacked on
for cases where interfaces make sense.
Whenever I've used dcollections (D1 included) I don't think I've ever used
the interface for a container, only the concrete type. But within
dcollections, there's some functions that use the interface type to do
(IMO) nifty things like compare two sets that have different
implementations.
The general consensus is that interfaces for dcollections do not add any
meaningful value, and that I should do everything with generic programming
and templates. My view is that interfaces are useful for binary
compatibility and in reducing the footprint of executables. But that
doesn't mean much at the moment, because D is statically linked.
I'd ask the naysayers of interfaces for dcollections, and also the
supporters: what is the point of having interfaces in D? Are interfaces
pretty much obsolete, and I am just nostalgic about their utility?
What do you think?
-Steve
