dcollections 1.0 and 2.0a beta released

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri May 21 10:42:14 PDT 2010


On 05/19/2010 08:42 PM, Steven Schveighoffer 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.

Without final, they are the roots of a hierarchy. But I understand you 
are making containers final, which is great.

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

This brings back a discussion I had with Walter a while ago, with echoes 
in the newsgroup. Basically the conclusion was as follows: if a 
container never escapes the addresses of its elements, it can manage its 
own storage. That forces, however, the container to be a struct because 
copying references to a class container would break that encapsulation. 
I called those "perfectly encapsulated containers" and I think they are 
good candidates for manual memory management because they tend to deal 
in relatively large chunks.

I noticed that your collections return things by value, so they are good 
candidates for perfect encapsulation.

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

I don't know Tango, but Java's containers are a terrible example to 
follow. Java's container library is a ill-advised design on top of an 
underpowered language, patched later with some half-understood seeming 
of genericity. I think Java containers are a huge disservice to the 
programming community because they foster bad design.

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

I need to disagree with that. I've done and I do a ton of binary 
interoperability stuff. You never expose a generic container interface! 
Interoperable objects always embody high-level logic that is specific to 
the application. They might use containers inside, but they invariably 
expose high-level, application-specific functionality.

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

I understand I could ignore the interfaces and call it a day, but it 
seems that at this point we are both convinced they are not quite good 
at anything: you only put them in because you suffered the Stockholm 
syndrome with Java, and I hate them with a passion.

Why would we keep in the standard library bad design with the advice 
that "if you don't like it ignore it"?


Andrei


More information about the Digitalmars-d-announce mailing list