Re: [boost] [xint] quick review

Subject: Re: [boost] [xint] quick review
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-03-14 10:59:41

AMDG

On 03/14/2011 02:35 AM, Domagoj Saric wrote:
>
> "Chad Nelson" <chad.thecomfychair_at_[hidden]> wrote in message 
> news:20110312020807.3aa7c86f_at_ubuntu...
>> The whole point of the library is unlimited-size integers. I plan to
>> improve the fixed-size integers, but they are not the primary focus of
>> the library.
>
> Then my acceptance vote remains a firm no...not just because such a 
> library will not fulfil my needs or satisfy my notion of a 'proper 
> implementation' but because you seem to fixed on the idea of adding a 
> library to Boost that primarily suits your needs in spite of objective 
> and validly argued demands from the Boost community. Your 'whole point 
> of the library' is exactly that, >your< point, I did not see any 
> reviewer agreeing with you on that point. All of this makes the 
> library not Boost.XInt but ChadNelson.XInt...
>
> And why exactly do you refuse to treat fixed-size integers 'properly 
> and equally'? So far the only reasons I could find are:
> - you have no need for them - a priori irrelevant if you want 
> inclusion in Boost

I don't think fixed size integers are necessary
for a Boost bigint proposal to begin with. However,
since are provided, I'd like them to be handled
as well as possible. Chad has already said that he
expects support for them to improve and that's
good enough for me, since it won't require breaking
the interface.

> - you do not have or do not want to spend time 'doing it right' - if 
> you listened to advice, various people repeatedly already gave you way 
> back in the earlier iterations of the library, to decouple orthogonal 
> concepts (namely algorithms from data storage) it would have been 
> trivial to add fixed-size support (i.e. almost as simple as choosing 
> between boost::array and std::vector). Probably a fraction of the time 
> spent arguing about it (and coming up with pointless arguments like 
> that of a 'performant swap')...

Pointless?

> The argument against separating algorithms so far has been that it 
> would expose a wider public interface with the addition of SW's 
> arguments against STL-like algorithms specifically. However, none of 
> those arguments apply to the sole idea of algorithm extraction as this 
> does not in any way imply that you have to make them public or 
> STL-like...They can still remain an internal implementation detail...
>
> The fact that you refuse to listen to advice, even such 'ancient 
> truisms' as 'decoupling is always right',

It isn't. If there's one thing I hate more than
anything else, it's blindly applying rules,
while forgetting the reason that the rules
exist to begin with.

> and even after your experience and/or knowledge has been shown as 
> lacking, cements the no vote even more because, as Dave Abrahams said, 
> the vote goes to the library and the maintainer...

In Christ,
Steven Watanabe