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