dcollections 1.0 and 2.0a beta released

[Robert Jacques]

On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:
> Andrei Alexandrescu Wrote:
>
>
>> To get back to one of my earlier points, the fact that the container
>> interfaces are unable to express iteration is a corollary of the
>> design's problem and an climactic disharmony.
>>
>> My vision, in very brief, is to foster a federation of independent
>> containers abiding to identical names for similar functionality. Then a
>> few concept checks (a la std.range checks) can easily express what
>> capabilities a given client function needs from a container.
>
> This might have a simple answer.  Dcollections implementations are not a  
> hierarchy, just the interfaces are.  I.e. there aren't many kinds of  
> HashMaps that derive from each other.  But the interfaces are not  
> detrimental to your ideas.  The only thing interfaces require is that  
> the entities implementing them are classes and not structs.  As long as  
> you agree that classes are the right call, then interfaces can co-exist  
> with your other suggestions without interference.
>
> Yes, if you want to define "this function needs something that is both  
> addable and purgeable, I don't have an interface for that.  But a  
> concept can certainly define that generically (which is what you want  
> anyways), or you could just say "I need a List" and get those functions  
> also.  It also does not force entities other than dcollections objects  
> to be classes, they could be structs and implement the correct concepts.
>
> I myself don't really use the interface aspect of the classes, it is  
> mostly a carryover from the Java/Tango inspirations.  But I can see one  
> good reason to keep them -- binary interoperability.  For example, it  
> might be the case some day when D has good support with dynamic  
> libraries that a library exposes some piece of itself as a Map or List  
> interface.
>
> So my answer is -- go ahead and define these concepts and required  
> names, and you can ignore the interfaces if they don't interest you.   
> They do not subtract from the possibilities, and others may find good  
> use for them.
>
> 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.