[boost] Re: Re: FORMAL review of "Output Formatters" - results

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-23 11:31:20

Sorry for quoting so much -- it all seems relevant. My suggestion for how to
proceed is at the end.

"John Torjo" <john.lists_at_[hidden]> wrote in message
news:4178C5A6.4010703_at_torjo.com...
> David Abrahams wrote:
> > John Torjo <john.lists_at_[hidden]> writes:
> >
> >
> >>Dear all,
> >>
> >>We got a lot of feedback relating the "Output Formatters" library [1].
> >>
> >>"Yes" votes : 4
> >>"No" votes:   2
> >>"Abstain" votes: 2
> >>
> >>Conclusions:
> >>- The docs and naming of the classes/functions could certainly be improved.
> >>- Seems a lot of people want this for pretty output, testing, debugging.
> >>- People don't need this library to provide ANY input facilities
> >>- quite a few people wanted a redesign.
> >>
> >>Thus, I wil consider this library "Pending Acceptation". In other
> >>words, it's considered Accepted by default, but since it will be
> >>redesigned, a new short review will take place.
> >
> >
> > I have no opinion whatsoever about the library's merits (I didn't
> > look), but what you're describing here surprises me.  The group's
> > reception to the library seems from the vote to have been lukewarm at
> > best and the library is going to be redesigned.  Of course review
> > managers have the perogative to render any verdict they like, and I
> > don't know what "Accepted by default" is supposed to mean exactly, but
> > it doesn't seem like an appropriate result given what was written
> > above.
> >
>
> I take back  "Accepted by default", since is a bit confusing, sorry for
> that.
>
> Here's what I mean:
> it's clear that people want such a library, and a lot of positive
> feedback was received. I know the library cannot be accepted at this time.
>
> Reece will redesign it, given the feedback and a new formal review will
> take place in about 3 months.

Are you also taking back your suggestion that the 2nd review be abbreviated? It
seems to me that the only reason to have a short 2nd review would be if some
preliminary conclusions had been reached in the first review. If I recall
correctly, there were at least 4 distinct ideas about how the library should be
redsigned, with no clear preference for one alternative among participants in
the review. If, as review manager, you believe there was enough consensus on
certain issues or you decide independently that certain solutions are
technically
best, you should state this in the review result.

Here are some of the open issues:
- Since renaming is required, what should the new names be?
- Should the library use locales and/or iword/qword?
- Should the library be a lightweight facility for debugging or a full-flegded
formatting facility which allows an object to be output in almost any possible
way?

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote:

> I would like it on record that I disagree with this decision.<snip> I
> still not sure that problem domain doesn't warrant library at all.

At the just completed Redmond meeting, the library working group voted to remove
tuple i/o from TR1, partly because of some difficulties with the specification.
But there was unanimous agreement that some standard i/o facility is needed for
all STL containers, and substantial support for a certain degree of
customizability.

Therefore, I think the best way to procede would be to develop two proposals,
which might be combined into one library:

1. An ultra-lightweight version which could be a candidate for standardization,
providing both input and output and minimal support for user customization. This
version should work by overloading operator<< in namespace std, and be
implementable with very little metaprogramming.

2. A highly-customizable framework for formatting more-or-less arbitrary types.
This proposal might be seen as an inverse to Spirit. IMO, it's worth pursuing
several of the ideas brought up during the review, to see how they compare. As
much as I'd like to see this happen soon, I think three months is unrealistic.

Best Regards,
Jonathan