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
