RE: [boost] Formal review of "Output Formatters" library begins today

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2004-09-13 09:31:25

| -----Original Message-----
| From: boost-bounces_at_[hidden] 
| [mailto:boost-bounces_at_[hidden]] On Behalf Of John Torjo
| Sent: 12 September 2004 13:41
| To: Boost list; boost-announce_at_[hidden]
| Subject: [boost] Formal review of "Output Formatters" library 
| begins today
| 
| 1. What is your evaluation of the design?  A good effort at a complex and
messy problem(s).

| 2. What is your evaluation of the implementation?  OK, but

* There is a terribly central spelling mistake which nobody seems to noted
so far:

  A _delimiter_ does de-limit things and has nothing to do with deli_s or
meter_s!
  A global search in replace in code and docs is vital.

  Unlike me, Boosters are obviously not native __English__ speakers ;-)

* I strongly dislike abbreviations and concatenations. It is MUCH easier to
read/understand and consistent with STL styling to use full words and _s, if
a bit longer to type. naryfmt really must qualify for some prize.
nary_format or n_ary_format.
  "Boost prefers clarity to curtness".

| 3. What is your evaluation of the documentation?  OK - 

  Though I am not a fan of background coloured boxes for code - I think the
font change is enough.

  One thing I would REALLY REALLY like is a Boost 'Standard' way of
colouring and indenting code similar to Visual Studio IDE - though I don't
feel their colour scheme is quite as good mine!

  Nor do I like Doxygen generated docs much - they never seem to tell me
what I want to know.

  And the grey-ed out backgrounded boxes obscures the Doxygen code
colouring.

| 4. What is your evaluation of the potential usefulness of the library?
Very useful.

| 5. Did you try to use the library? Yes previously worked OK.
   
| 6. How much effort did you put into your evaluation? About an hour
re-reviewing previous work.
|   
| 7. Are you knowledgeable about the problem domain? A would-be user.

| 8. Do you think the library should be accepted as a Boost library?   Yes -
but with some name changes.

And I would like to see active work by all authors to ensure that this
interacts with the filtering, range, more_io libraries before the first
actual full release (in 1.33?) so that the documentation cross-references
too, including examples of combinations of these techniques.

I can understand that authors are unwilling/unable to work together until
they are sure which other libraries can be assumed a part of Boost, and I
think we must accept (and flag up) that there will probably be changes,
perhaps major, while interworking is perfected.  The three recent IO
contributions, with serialisation, are prime candidates for mutual
refinement. 

Paul

Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone]  [phone]
mailto: pbristow_at_[hidden]