Steven Schveighoffer wrote:
On Mon, 24 May 2010 14:10:26 -0400, Walter Bright
<[email protected]> wrote:
Steven Schveighoffer wrote:
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?
Interfaces are for runtime polymorphism, rather than compile time
polymorphism. They are especially useful for things like:
1. runtime plugin interfaces
2. designs where strict implementation hiding is desired
3. to have binary libraries (shared and static)
4. to support Java/C# style coding
5. reduced code memory footprint
6. experience shows they are an excellent fit for user interfaces
Compile time polymorphism, such as what templates provide, are most
useful for:
1. maximum performance
2. minimal data memory consumption
3. better compile time checking
I believe the tradeoffs for collection types favor compile time
polymorphism because:
1. performance is often critical for collections
2. C++ STL has shown the success of this approach
3. collections must fit in naturally with ranges, and ranges are
compile time polymorphic
I'd counter point 2 by saying that 1. C++ classes are value-types by
default and 2. C++ doesn't have interfaces, so it's not exactly fair to
say that the STL author considered interfaces but rejected them.
C++ certainly does have interfaces. The whole COM system is based on them, for
example. Technically, D interfaces are just a subset of C++ multiple inheritance.
and on point 3, why is it not OK to *also* provide interfaces in
addition to ranges as dcollections does? That is, take away
dcollections' interfaces, and you have essentially compile-time
polymorphism, they all support ranges etc. Interfaces are also there in
case you want to use them in things like runtime plugin interfaces.
The best reason I can think of is to avoid kitchen-sink style components.
Components should do one thing well. Adding capability should be done with
aggregation by the user.
Basically, my point is, compile time interfaces does not mean you can't
also have runtime interfaces. In fact, interfaces can be compile-time
parameterized.
Sure, but I'd argue that adding such runtime polymorphism should be done with a
separate add-on component. It should not be part of the collection component.
Also, much of a user interface consists of various collections
(listview, treeview, child widgets, etc.). Why is runtime polymorphism
good there, but not on a generic collections package (not as the only
means of access of course)?
A user interface object is not a collection component, I think there's a
confusion in the design there.
