On 1/29/11 3:36 PM, dsimcha wrote:
I've uploaded the documentation to
http://cis.jhu.edu/~dsimcha/randaasealed.html and mentioned it again on
the mailing list. The documentation is pretty sparse because
interface-wise it's just a standard hash table. More generally, though,
are we still interested in sealed/ref counted containers?

Sorry for being slow in continuing this thread.

Regarding the general issue that someone makes an informal proposal (either here, as a DIP, or on the Phobos mailing list), followed by a thundering silence: I believe that a good technique is to formalize the proposal review process, which has been a homerun for Boost. The disadvantage of that is that almost without exception this is very taxing to library submitters. This means the submitter must put a lot of thought and a lot of work into motivating, polishing, and documenting an artifact without any guarantee that it would lead to inclusion in the target library. I've seen very, VERY elaborate Boost submissions fail - literally months of work gone to waste.

I'm not sure how to save people from doing work up front in hope of an uncertain outcome in the future.

I do know what does _not_ work: the take it or leave it approach: "Hey, I have this code for abstraction XYZ that I extracted from a project of mine and I think it may be of general interest. It's at http://site.com/path/to/code.{d,html}. It needs polishing here and there, it's largely undocumented, but I'm sure the ideas shine through. Eh?"

The doc at http://cis.jhu.edu/~dsimcha/randaasealed.html is somewhere in between. It is clear you have a good understanding of sealing and hash containers, but let me ask you this - if you wanted to sell this to someone, what would you do? Probably you'd show some relevant benchmarks putting the built-in hashes to shame. Maybe you'd have some good examples - yes, we know it's a hash, but it doesn't hurt to see some code pulp over there. Maybe you'd explain sealing and discuss its relative advantages and disadvantages (which have not yet been documented anywhere - a great opportunity). Maybe you'd even show some numbers showing how sealing does as well/better/worse than reference leaking.

This is a good amount of upfront work for little promise. Again, I don't know yet how to optimize for minimizing that. What I did see works on Boost is a request for interest in the form of a discussion (usually with NO source, only USAGE examples) asking if there are people who are interested in such a notion. In this particular case, you'd need numbers to make a strong case which means that code must be already written. For something like e.g. "how about a Finite State Automaton library?" perhaps upfront code wouldn't be necessary for gauging interest.


Andrei

Reply via email to