On Fri, 23 Jul 2010 20:05:21 -0400, BLS <[email protected]> wrote:
On 22/07/2010 23:00, Steven Schveighoffer wrote:
collections has a feature where you can swap the underlying
implementation for something completely different.
ATM I find it pretty hard to implement an other underlying
implementation for dcollections.
Say an LL RBTree or an Skiplist for dcollections.
I hope we can talk about how to fix it, send me an email. AFAIK, nobody
(including myself) has tried to swap out implementations, so the "able to
swap out implementations" is only a theory :)
Perhaps the feature can't work, I'm not sure.
1) You've placed a couple of things into the node structure. and IMO it
is not always clear why.
Yeah, documentation is poor. Please let me know the issues, and I can
explain. Eventually, I want to document everything properly.
2) I am still not happy with your Node(V) instead of Node(K,V) decision.
I know about your reasons, but to be honest with you, I am not sure if
it's worh the additional programming effort needed for a key-value
implementation OR the reduced lines of code just to generalize the
node/tree so that it can also handle a vector. f.i)
For me this reduction to c!V . (funny enough) creates old bloated/messed
up code
void* abc(int i, bool A = true, bool B = true, int
in_a_very_special_case_here_another_thingy = 0, int
cause_DEF_requires_this_param = 0)
But heck I can be wrong. Still, comparing for equality seems to be
bloated, and (somebody else raises this up), how to implement multi-
index with just having c!(V)
Let's work to fix it. I want dcollections to be as usable as possible.
-Steve
