dcollections 1.0 and 2.0a beta released

[superdan]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> 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.

classes suck ass. structs give ye freedom 2 define copy ctors n shit. haven't seen
andre agreein' classes are da way 2 go and i hope he don't. anyway u put together
some cool shit. hope andre & u do a pow-wow n shit and adjust shit fer puttin'
into phobos.