dcollections 1.0 and 2.0a beta released

[Steven Schveighoffer]

On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

> On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
>> Robert Jacques Wrote:
>>
>>> On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
>>> >
>>> > Does that make sense?
>>> >
>>> > -Steve
>>>
>>> Yes and No. I understand where your coming from, but I think it's a bad
>>> idea. First, I think it needlessly expands the radius of comprehension
>>> needed to understand and use the library. (See Tangled up in tools
>>> http://www.pragprog.com/magazines/2010-04/tangled-up-in-tools) Second,  
>>> I
>>> think designing a library to be flexible enough to meet some future,
>>> anticipated need (e.g. dlls) is a good idea, but actually implementing
>>> vaporous future needs is fraught with peril; it's too easy to guess  
>>> wrong.
>>> Third, interface base design is viral; If library X uses interfaces  
>>> then I
>>> have to use interfaces to interface with it. And if another library Y  
>>> uses
>>> classes, then I'm going have to write a (needless) wrapper around one  
>>> of
>>> them.
>>
>> I understand these points, but I'm already using interfaces to copy  
>> data between containers.  I don't have to, I could have used generic  
>> code, but this way, only one function is instantiated to copy data from  
>> all the other containers.  The problem with using generic code is that  
>> the compiler will needlessly duplicate functions that are identical.
>
> This sounds like a failure of design. Why aren't you using ranges to do  
> this?

Why are ranges necessarily better?  I'm using the container's opApply,  
which I'd probably still use even if there were no interfaces.  opApply  
allows much more possibilities in traversal than ranges which cannot use  
stack recursion without heap activity.

>
>> Using interfaces is not as viral as you think.  My interfaces can be  
>> used in generic code, as long as the generic code uses functions in the  
>> interfaces.  If a library returns an interface, the author is saying "I  
>> don't want you using any functions outside this interface," so why is  
>> that a bad thing?
>
> Well, needlessly duplicated functions for one. :) More importantly, the  
> example I gave was about third party libraries which I have no control  
> over. So this solution explicitly doesn't work. And even if everyone  
> used templates everywhere in order to be compatible with both interfaces  
> and classes, isn't that a viral effect of having both?

If a 3rd party library uses interfaces, it's probably for good reason.   
They most likely want to remain binary compatible with other libs, and/or  
want to abstract the implementation of some custom container type.  If you  
don't like their requirements, don't use the library.

-Steve