Decision on container design

[dsimcha]

I see your point.  Some of the stuff I've posted lately (RandAA, 
CsvRange) is in a usable but admittedly rough state, and was written 
partially for myself and partially for Phobos.

If this came off as take-it-or-leave-it, this was unintended. These 
posts were supposed to be informal requests for comment.  My main goal 
in these posts was to gauge whether there's enough interest, whether the 
design was good enough that it's worth polishing up for Phobos, and 
whether I missed any key features.  If there was sufficient interest I 
had every intention of polishing/fleshing out these libraries.

On 2/1/2011 11:00 AM, Andrei Alexandrescu wrote:
> 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
>