phobos alt.

[Steven Schveighoffer]

On Sat, 29 Oct 2011 22:14:34 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 10/29/11 7:17 PM, bls wrote:
>> On 10/29/2011 04:58 PM, Vladimir Panteleev wrote:
>>> td.container seems to have been written by the very same Steven
>>> Schveighoffer.

Just the RBTree portion (and Jonathan Davis has fixed a lot of issues with  
it since then).  Andrei insisted my name come first because my  
contributions occupied the most real estate ;)

>>
>> Well, that's not quit right. Steven has done a lot of things on
>> std.container, (especially algorithm wise, RB Tree f.i.), but the senior
>> designer is Andrei.
>> But I thing it's up to Steven to explain the political thingies.
>
> There is no politics at play. Steven and I respect each other's design  
> choices and we agree to disagree on a few decisions that could  
> reasonably go either way. He has graciously accepted to alter his RBTree  
> API to integrate it with Phobos.

I agree with Andrei here.  Andrei asked me to incorporate RBTree into  
std.container, and I did it because it took me quite a while and wrestling  
with my CLR algorithms book to get it right, and it was an easy thing for  
me to contribute to phobos which would have been likely painful for  
another developer to do ;)  I don't hold anything against phobos for not  
wanting my collections library, I'm perfectly happy using it as a  
third-party lib.  I suspect if dcollections were to gain traction by, say,  
being used in large projects, competition would force std.container to  
become developed.  It's somewhat how std.container came into existence  
anyways (the announcement of dcollections for D2 forced the issue), and it  
pushed the current tango container lib along when I tried proposing it to  
replace Tango's lib.

If at some point std.container satisfies my needs for a collection library  
design-wise, I'll happily switch over to using it and incorporate as much  
dcollections as I can into std.container.  But right now, I find the  
design woefully inadequate/clunky.  Just my opinion.  I also quite enjoy  
having my own side-project to tinker with :)

I encourage anyone to port any portion of dcollections to std.container.   
If nothing else it will help flesh out the design of std.container (or  
even dcollections).  But you will not find me using it until cursors and  
deletion-while-iterating are added.

>> Just want to say that > Phobos don't have a boost like container library
>> and dcollections is already offering something beyond. (cursors)
>> AGAIN why not having alt.container ??
>
> This is an invite to gratuitous balkanization. std.container is open for  
> contributions. If anyone wants to add to it, they would need to pass it  
> through the review process. The design is well-defined enough to make  
> e.g. a DList implementation free of any dilemmas.

I don't wish to create a secondary "standard" library.  Having a third  
party version is good enough, and people are free to use it or not, it  
does not need some sort of "official" status.  I think a good container  
library helps when you need it for other parts of the standard library.  I  
have no doubt the design of std.container will be revisited when other  
parts of phobos try to use it and find it lacking.  Necessity is the  
mother of invention.

I do wish dsource would get its act together and start trimming dead wood,  
dcollections (and other good active projects) are buried in it.  I try to  
bring it up when the issue of collections comes up on the NG, which is  
about all the press I get ;)  I might switch to github, I've found git  
pretty nifty.  And my documentation for dcollections 2.0 is long overdue...

-Steve