This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
scgmille@xxxxxxxxxxxxxxxxxx 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