Re: [boost] [xint] quick review

Subject: Re: [boost] [xint] quick review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-25 08:00:44

Domagoj Saric wrote:
> "Stewart, Robert" <Robert.Stewart_at_[hidden]> wrote:
> > Chad Nelson wrote:
>
> > It does, however, clarify the purpose and theme of the library.
>
> That purpose is, IMNHO, just/yet another issue on the 'review
> debating table'...

Certainly.  That should be part of your vote for or against the library, but it isn't necessarily important to other's votes.  If others can accept the library with unlimited length integers and accept that the fixed length integer support, if retained, is less than ideal, then they will vote to accept.  Your views have been expressed repeatedly but that doesn't make them more important than when first stated.

> Most specifically (to really repeat myself ad nauseam) because
> there is no real objective reason not to 'repurpose' it
> differently (make no first-class/second-class citizen
> assumptions)

There is a real, objective reason to not refocus the library: Chad has expressed a lack of desire for doing so.  Since he must write, document, and maintain the code, it isn't your place to force him to do so.  You may have good arguments for your position, but they needn't be authoritative to Chad.

> because it is relatively trivial to do so while at the same
> time providing benefits for a wide area of real world usage
> scenarios (e.g. the mentioned cryptographic keys...)...

There's no argument that the fixed length integers can be beneficial to some (possibly large) subset of developers.  For example, while I've never done any cryptography, I can see how high performance, fixed length integers would be beneficial in financial computations.  That doesn't, however, require that Chad include them in his library.

Whether supporting fixed length integers is "relatively trivial" (relative to what, I wonder), that is not, or has not, been obvious to Chad if for no other reason than he views the idea relative to his current design/implementation.  If you're right, and Chad redesigns his code and recognizes how to support them easily and is willing to take them on, then the library benefits and you'll be ecstatic, I'm sure.  However, many things must occur to reach that state, not least Chad's need to investigate removing COW and factoring out the algorithms.  Is it a surprise that he wishes to restrict the library's focus to reduce the scope of that work instead of also adding improved fixed length integers?

> >> Perhaps translation *is* needed, because what I'm hearing is
> >> that because I insist on disagreeing with you, there must be
> >> something wrong with my attitude.
> >
> > As far as I can see, Domagoj is using argumentative and
> > aggressive language to drive home his point that fixed,
> > but extended length integers are important and that XInt
> > is not acceptable without them.  Whether there had been
> > prior communication on solutions is almost moot.  Either
> > Chad didn't see the suggestions or had reasons to reject
> > them at the time.  Thus, the library being offered is XInt,
> > not Domagoj's version of it.
>
> Chad did see them, unless we accept the unlikely chain of
> events in which he was able to miss exactly just the specific
> points in many of the posts which he certainly did see as he
> replied to them...

Does it follow that Chad understood what he read in the way you meant it?  Furthermore, I noted that he may well have "had reasons to reject [the suggestions] at the time."  You may prefer that he hadn't rejected them or you may think his reasons flawed, but he's under no obligation to accept other's suggestions.

> and was then additionally pointed to the fact that he ignored
> pieces of argumentation.

You seem to forget that communication requires two people and is particularly hard in written communication between strangers.  One must write clearly and present information so the other party understands what's intended and how it applies in the context.  The second party reads words with a certain mindset that may not match that of the first party.  Thus, the second party may understand the words to mean something quite different from what was intended and, thereby, misunderstand and misapply them.

Concretely, isn't it possible that Chad understood things other than you intended and considered them to apply differently to his library than you meant or that he failed to grasp how what you suggested could even work because he failed to understand something critical in your suggestion?  Chad has gotten advice from a great many people and has learned that not all participants in this list are equal in skill.  Therefore, it's not surprising that he would take your suggestions with some skepticism, particularly if they didn't fit his mindset.

> And again, I was not the first to point this out (if I recall
> correctly Mathias Gaunard objected to the very same thing)...

I understood your earlier remark on this point to be a reference to prior discussions -- last year, perhaps -- on the library, not to discussions during the review.

> Additionally, Chad had no (or at least did not provide any)
> valid reasons to reject those objections and arguments. The
> only one I can recall is the constantly repeated circular "I
> will not focus on f.s.i because I will not" argument which of
> course simply begs the question. It was sometimes expanded
> with "because I do not have time to do it or do not know how"
> and then simply ignored counter arguments that it is
> relatively trivial to do it and various ways on how to
> actually do it...

I fail to understand how a library author's lack of interest in a feature of interest to any audience is a problem.  The question is whether the library, as presented, is useful and well designed, not whether it could do more.  Suggestions for improvement or extensions to the library are useful, but it is solely the author's decision whether to accept them.

If a reviewer finds the lack of some feature as critical, that reviewer may reject the library, but I consider such a review flawed because it can deny a useful library from Boost users.

Note also what you find trivial or obvious is in no way indicative of what another will find trivial or obvious.  Thus, your insistence that Chad is unreasonable to reject your ideas -- which I don't think he did outright reject, but rather indicated he would consider for possible incorporation after dealing with a great many other things -- is, itself, unreasonable.

> > Nevertheless, it may well be that the result will enable
> > Chad to understand how to provide fixed length integers
> > better than he's done thus far.
>
> A prerequisite for this is for Chad to actually want to
> provide proper fixed-sized integers, i.e. give them 'focus'...
> and, IMO, a prerequisite for this to be done is to stop
> treating them just as an 'ugly patch on an otherwise
> hardwired-dynamic-xint that others force me to do'...

Until Chad understands and accepts a view similar to your own on the design of the library, another view prevails.  In his present view of things, it is clear that fixed length integers are sufficiently different to be a problem for him to support beyond what he has now done.  He is under no obligation to accept your view, though hopefully he will spend sufficient time to understand it fully in order to knowledgeably accept or reject it.

> > Perhaps Domagoj can offer to review future versions and
> > make *constructive* comments at that time.  I'm reasonably
> > confident that Chad will accept those comments and act upon
> > them if he understands them
>
> Sorry but LOL...I really hope that you simply did not follow
> the discussion so far in order to give such a comment...I
> did, as did others to whose objections Chad reacted as '
> attempts to kill the library', give constructive comments (not
> only in this discussion but in previous ones also). And often
> Chad simply refused to 'accept' those comments or dismissed
> them for dubious reasons...

What I saw was Chad's attitude change significantly in the middle of the review.  He became far humbler and more willing to listen to other viewpoints and respond more reasonably than he did at first.  As Dave put it, "the process works!"  By contrast, you continue to attack and rail at him as if nothing changed.  Consequently, I find your behavior to be more troublesome.

> > and finds them consistent with his vision for the library.
>
> And we arrive at the key point...Is his, or anyone else's
> vision for that matter, not also a debatable matter?

It is debatable, but Chad needn't change his vision as a consequence.  If an author's vision makes a library unacceptable to you, then vote against it.  You should state your *opinion* on the matter and let it go.  It's that last part you seem to be struggling with in this case.

> When I started to work on my GIL.IO2 proposal, I went out of
> my way to support and provide support for a wide range of use
> cases (of which I personally need just a tiny fraction) simply
> accepting the fact that there is an obvious difference between
> a Boost.Library and a JohnDoe.Library...

That's terrific.  Doing so, however, meant that you chose to take on more work.  Thus far, Chad's been reticent to *commit* to doing that.  That doesn't mean the unlimited length integer capability suffers as a consequence.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.