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
