dcollections 1.0 and 2.0a beta released

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri May 21 10:55:50 PDT 2010


On 05/19/2010 09:59 PM, Robert Jacques wrote:
> 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)

For the record, I strongly agree with this.

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

That's a good argument as well. I like to put it a different way: you 
can get the advantages of an interface by wrapping a struct, but you 
can't get the advantages of a struct by wrapping an interface.


Andrei


More information about the Digitalmars-d-announce mailing list