dcollections 1.0 and 2.0a beta released

[superdan]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> superdan Wrote:
> > == 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.
> I think classes are the right move.  First, a collection makes more sense as a
reference type.  Note that both arrays and associative arrays are reference types.
 If collections are value types, like in C++, then copying a collection that is a
node-based collection means duplicating all the nodes.  Copy construction is
essentially possible through a function -- dup.  Having value-semantics makes it
too easy to copy large amounts of heap data hurting performance.  Many
inexperienced C++ coders pass a std::set by value, not realizing why their code is
so ridiculously slow.  I think one of the things that makes D so damn fast is
because large data structures such as arrays and AA's are always passed by reference.
> Second, since reference types are the right thing to do, classes are much easier
to deal with.  I know AA's are reference types that are structs, but the code
needed to perform this feat is not trivial.  The AA has only one member, a
reference to the data struct, which is allocated on the heap.  Any member
function/property that is used on the AA must first check whether the
implementation is allocated yet.  The only benefit this gives you IMO is not
having to use 'new' on it.  And even that has some drawbacks.  For example, pass
an empty AA by value to a function, and if that function adds any data to it, it
is lost.  But pass an AA by value with one element in it, and the new data sticks.
 A class gives you much more in terms of options -- interfaces, builtin
synchronization, runtime comparison, etc.  And it forces full reference semantics
by default.  I think regardless of whether interfaces are defined for
dcollections, classes give a better set of options than structs.
> Also note that I intend to make all dcollections classes final, so there will be
no virtual calls as long as you have a reference to the concrete type.
> Is there some other reason to use structs besides copy construction?
> -Steve

memory management n shit. with a struct u can use refcounting n malloc n realloc n
shit. still stays a reference type. nothing gets fucked up.

den there's all that null ref shit. with a class u have

void foo(container!shit poo)
{
    poo.addElement(Shit(diarrhea));
}

dat works with struct but don't work with motherfucking classes. u need to write.

void foo(container!shit poo)
{
    if (!poo) poo = new container!shit; // fuck dat shit
    poo.addElement(Shit(diarrhea));
}

u feel me?