dcollections 1.0 and 2.0a beta released

[Robert Jacques]

On Mon, 24 May 2010 08:06:29 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:
> 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:
[snip]
>>>
>>> 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.

Ranges are not necessarily better and may have some minor amount of  
overhead over a well optimized opApply. Then again, the opposite may be  
true. The point is that if the difference between opApply and a range is  
more than trivial, you've probably had a failure of design occur.  
Honestly, I'm having trouble thinking of a container which allows stack  
recursion for transversal and doesn't have an efficient range/loop  
variant. For that matter, a range using heap activity is also a clear  
indication of a design failure.

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

No, if a 3rd party library _needs_ to use interfaces it's probably for a  
good reason. The problem is, if they exist, people are going to use them  
even if they don't need them. Which therein lies the problem.