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