To interface or not to interface

[Steven Schveighoffer]

On Mon, 24 May 2010 14:36:57 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> 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 if STL looked like COM, I think it would have been a miserable failure  
indeed.

>
>> 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.

What if it can do both things well (I would propose that dcollections  
does)?

>
>
>> 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.

So I should specifically have to wrap a collection type in order to make  
it runtime polymorphic, forwarding all the operations to the collection?   
Essentially something like:

class WrappedSet(Impl, V) : Set!V
{
    Impl!V impl;

    bool contains(V v) { return impl.contains(v);}
    ...
}

For what reason?  Why is it so bad to just stick Set!V on the end of the  
implementation class?

>
>
>> 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.

Don't user interface objects have data?  If a UI component is an  
interface, how does it expose access to its data?  For example, a .NET  
ListView control contains an Items property which you can use to access  
the elements in the list view.  The Items property returns a  
ListViewItemCollection which implements IList, IContainer, and  
IEnumerable.  I've found these types of abstractions useful when  
adding/iterating, etc.

-Steve