dcollections 1.0 and 2.0a beta released

[Steven Schveighoffer]

On Mon, 24 May 2010 12:06:18 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

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

The difference is trivial.  I support both ranges and opApply.  The main  
benefit from using opApply being only one function is compiled by the  
compiler.

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

And if 3rd party X _needs_ to use interfaces, and 3rd party Y _needs_ to  
use interfaces, and your code depends on X and Y, and interfaces aren't  
defined by dcollections, where are you then?  I don't think there's any  
way you can define a generic standard library such that people won't  
create bad designs, that's a lost cause.

I think part of the problem with all this is that interfaces aren't likely  
to be needed any time soon (D's dynamic lib support is almost  
non-existent), so I'm probably going to drop the interfaces for now in the  
interest of progress.

-Steve