Decision on container design

[Andrei Alexandrescu]

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