On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
<[email protected]> 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.
