D library projects

BLS windevguy at hotmail.de
Sun Nov 15 12:53:08 PST 2009


On 15/11/2009 18:19, Steven Schveighoffer wrote:
> On Sun, 15 Nov 2009 04:18:51 -0500, BLS <windevguy at hotmail.de> wrote:
>
>> On 14/11/2009 20:58, Steven Schveighoffer wrote:
>>> collections will be D2 eventually. It already supports D1 via Tango or
>>> Phobos. I want to make it aware of D2-like features (const, ranges,
>>> etc), so it's not just a simple port.
>>>
>>> http://www.dsource.org/projects/dcollections
>>
>> I think is very well done and hope for a D2 port.
>
> Thanks!

dCollections are really outstanding ... super clean code, flexible 
allocators, change of the underlying algo. Just a 5* WOW.

>
>>
>> Just two notes :
>> 1) I think the Collection Interface should contain removeAll()/wipeOut()
>>
>
> Does Collection.clear() not fit the bill?
>
>  From docs:
>
> * Collection!(V) clear ();
> clear the container of all values
>


Mea culpa. Sorry , should read the source more carefully.


>> 2) I prefer ICollection instead of Collection. cause D just uses :
>> instead of implements.
>
> It is a good point. I shied away from IXxx for interfaces because of how
> much loathing I had for MFC's nomenclature, but it would make sense to
> change it. I also was originally writing dcollections for inclusion into
> Tango, so I followed the existing naming scheme there.
>
>>
>> You wrote :
>> Able to swap out underlying implementation of a container, or
>> customize implementation. ***
>> ***class TreeMap(K, V, alias ImplTemp=RBTree,
>>
>> This mean that f.i. I am able to replace your RB Tree implemtation for
>> TreeMap with f.i. LL RB Tree. Right ?
>
> Yes.
>
>> Guess what I want to ask is : What do I have to keep in mind to give
>> it a try ?
>
> The comments are outdated, but there is a list of functions your
> implementation must have. For example see:
>
> http://www.dsource.org/projects/dcollections/docs/current/dcollections.TreeMap.html
>
>

Thanks, will do.

> The beginning documentation sort of outlines a list of functions
> necessary. But I've changed around things such as e.g. how the compare
> function is passed. It used to be a delegate, now it is an alias passed
> to the implementation template.
>
> My recommendation is to look at the methods and properties of RBTree
> struct in this file:
> http://www.dsource.org/projects/dcollections/docs/current/dcollections.RBTree.html
>

Already done :)


>
> Try to implement those basic methods and properties, and I think it will
> work. I will eventually get around to fixing that documentation to
> reflect the correct requirements. Once I port to D2, however, I can use
> template contracts and hopefully that is more self-documenting.
>
> If you have trouble, please submit tickets on the dsource web site, I
> will try to fix whatever is wrong. You are the first person I know of
> who wants to test this feature, so I'm interested in how it works out :)

I am afraid I have to 'cause of mistakes.

> Also if you get a good implementation together, and are willing to
> contribute, I can incorporate it into dcollections.
>
> -Steve

I could imagine (and would like) to contribute  a clean Skip List, and 
LL RB Tree  implementation for dcollections.

==
Now : Sorry for my ignorance ... but Why the heck :

struct RBNode(V)

instead of :

struct RBNode(K, V)

Björn



More information about the Digitalmars-d mailing list