To interface or not to interface

[Steven Schveighoffer]

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.

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.

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.

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)?

-Steve