To interface or not to interface

Steven Schveighoffer schveiguy at yahoo.com
Mon May 24 13:47:13 PDT 2010


On Mon, 24 May 2010 16:27:40 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> On Mon, 24 May 2010 14:36:57 -0400, Walter Bright  
>> <newshound1 at digitalmars.com> wrote:
>>>> 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)?
>
> Probably for the same reason I don't want a microwave built in to my TV  
> set. It's not a question of can it do both well, it's a question of is  
> it a distinct component or not.

We're not talking microwave and TV set here.  We're talking more like  
microwave and a cooking device.

>
>
>>> 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?
>
> Because then everyone who just wants a hash table winds up carrying  
> around the complexity for things they don't want. The idea behind  
> pluggable components is that each component should be minimal, and then  
> the user aggregates them to meet his needs.

What extra complexity?  That's what I'm trying to get at, there is none.   
The complexity of "being a set" is builtin to the fact that HashSet is a  
set!

>>>> 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?
>
> That's up to the UI interface designer. It has nothing to do with how it  
> implements the collection under the hood.
>
>> 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.
>
> A graphical component can wrap a collection component. I see no reason  
> why the collection needs to have runtime polymorphism to enable that.

It's a logical conclusion.  You provide a map-type collection, call it a  
HashMap.  Then, a UI designer wants to abstract his specific Map-like  
container that exposes his elements, so you provide him a Map interface.   
But HashMap implements all the required functions to be able to implement  
the Map interface, so you slap Map on the back of the class definition,  
and presto!  It implements the map interface.  Where's the extra  
complexity?

I don't see how that's a bad thing.

-Steve


More information about the Digitalmars-d mailing list