xxxxxx@freenetproject.org wrote:
>>> Tough.  That is the only way you'll convince me of a flaw.  No
>>> amount of positive proof through implementation is likely to satisfy
>>> you.

Bradd W. Szonye wrote:
>> That's nice. I suggest that you take your proposal to a venue where:
>>
>> 1. The burden of proof is on the reviewers rather than the author, and
>> 2. Designers are not required to support their proposals with concrete
>>    implementations.
>>

> The burden of proof certainly rests on the author when there are valid
> criticisms.

In the SRFI Process, "Your implementation is incomplete" certain is a
valid criticism.

> Its unreasonable to expect an author defend against vaporous claims.

It's not vaporous, your implementation *isn't* complete.

> But its a waste of everyone's time to dwell on subjective notions of
> what makes a good interface without suggestions on how to get there.

This isn't the forum for hashing out the solutions or proposing
alternatives. That's true both for code reviews in general and for the
SRFI review process specifically. You use the review to bring up
objections, like "the implementation is incomplete," and you use another
forum to discuss solutions.

Unfortunately, you won't even accept that the issue exists or that it's
important, so it's pointless to discuss it in another forum. As Bear and
I have both pointed out, you simply aren't paying attention to issues
that you don't want to deal with. I don't feel that discussing this
offline would be a good use of my time.

I've been on the receiving end of reviews like this one. When it
happens, there isn't much you can do but withdraw the product under
review, work out the major issues, prepare the reviewers with background
docs, etc., and re-present the product for review when it's ready.
That's why I've been recommending that you withdraw the SRFI. Reviews
aren't the place to hash out major issues.

Sometimes, a review reveals that the author's design goals are
incompatible with the reviewers' requirements. In that case, detailed
review is particularly fruitless. I think that's the case here: Your
design goals are sufficiently different from what I consider important
in a collection class that we're unlikely to resolve all the
differences.

I do recommend that you revisit your design goals, because I feel that
they're inappropriate given the audience for your product. Bear and I
have both been trying to warn you of this. That's an issue that can't be
resolved with a just few tweaks before release. Also, the risks and
costs of failure are very high. A low-quality interface standard causes
more problems than it solves, and an untested interface standard has a
high risk of low quality.

And finally, no matter how many excuses you make for it, your
implementation is still incomplete and should, in my opinion, be
rejected by the editors.
--
Bradd W. Szonye
http://www.szonye.com/bradd