To interface or not to interface

[Jacob Carlborg]

On 2010-05-24 21.08, Steven Schveighoffer wrote:
> 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


I would say that is a bad design, I would go with the MVC pattern. For 
example, you have a ListView and when it's ready to display, say row 3, 
it calls your delegate and request you to return the item that should be 
visible on row 3. Then it's up to you to store the items in some 
appropriate data structure, like a list or array.

-- 
/Jacob Carlborg