contain-rs / discuss

A center for discussion and planning of the contain-rs organization.
5 stars 0 forks source link

What does contain-rs want to host? #1

Open Gankra opened 9 years ago

Gankra commented 9 years ago

Hosting All The Implementations is burdensome and confusing. What's our threshold for including an implementation? Like, if someone implements 10 BSTs, do we accept them all? or only accept the variants that we don't have? Or accept only the ones that have a distinct performance advantage? Should exotic features have mandatory associated use cases?

Do we start rejecting naive implementations and start requiring that they're actually optimized (certainly many of my contributions would fail this threshold!)? How much of the API should be fleshed out? Who's responsible for longterm maintenance of collections? Right now it's basically @apasel422 being a hero while I fumble through grad school. Should we require some kind of hard communism law of "we'll maintain your shit if you maintain our shit"? Does that require kicking things out?

reem commented 9 years ago

I definitely have an internal metric for what I think is appropriate, but I'm having a hard time articulating a precise rule vs. just my intuition.

huonw commented 9 years ago

I think the long-term maintanence burden is inflated by being pre-1.0 and things will get easier once stability kicks in properly. (Also, the new automation should make things easier?)

apasel422 commented 9 years ago

Aside from the collection implementations themselves, I think contain-rs should be investigating and iterating on new conventions and techniques that apply broadly. The comparators and ordered iterators are an example. With regard to BSTs, instead of accepting a bunch of implementations, I'd love to see one solid implementation that is generic over things like the balancing operation and augmented data. We need to explore how Rust libraries can support advanced features like these so that the standard library collections aren't underpowered (e.g. BTreeMap should eventually use comparators [whatever those end up looking like], and it would be interesting if HashMap could expose some kind of interface to make LinkedHashMap easier to implement safely).

fbstj commented 9 years ago

would it be potentially possible to set up mirrors/clones of various other implementations? I don't know if that is the sensible route? does defining 'good quality interfaces' and allowing efficient and safe 'pluggable' backends seem plausible? throws suggestions around