dcollections 1.0 and 2.0a beta released

[Steven Schveighoffer]

On Fri, 21 May 2010 14:00:42 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 05/20/2010 05:34 AM, Steven Schveighoffer wrote:

>> 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.
>
> There is a copy() function that copies any range to any other range. It
> might need a revisit, but I think the way to go about copying is generic.

This implies the space for the elements already exists in the target  
range.  Copying data from a list to a set for instance can't just allocate  
space in the set and then use some generic copy function to copy the data  
in.

If generic copying is to be used, it would be a copy function defined by  
the collection, not a standard one.

>
>> 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?
>>
>> Forcing people to *not* use interfaces has its drawbacks too.
>> Dcollections gives the most flexible design I could muster, while
>> still being useful.
>>
>> I'm not saying I'm against removing the interfaces until some later
>> date, but I don't see any convincing arguments yet, especially since
>> I've already seen benefits from having them.
>
> What are the benefits that you have noticed? I think you'd need to back  
> up the copying argument with some data if you want to frame it as a  
> benefit.

When I mean see benefits, the benefits are not data-related but design  
related -- more designs are possible with interfaces and generic  
programming combined than with generic programming alone.

-Steve