To interface or not to interface

[Walter Bright]

Steven Schveighoffer wrote:
> On Mon, 24 May 2010 14:10:26 -0400, Walter Bright 
> <newshound1 at digitalmars.com> 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.