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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-10-25 05:14:05

>>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

I will prefer an abbreviated review. Depending on how much feedback is 
received, I might choose to extend it.

> 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?

Renaming can happen at a later time (not now, that is). It can also 
happen during the review. It's happened before. Also, this is relevant 
if the library is accepted.

> - Should the library use locales and/or iword/qword?
                                                 ^ pword, that is
This is an implementation detail.

> - 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?
> 

It should be an in-between.

> 
> 
>>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.

For starters, I thinkg you should be able to use boost.serialize.

Otherwise, I think something very trivial could be:
- provide support to write an array, with delimeters (open, in-between, 
close).
- provide support for writing a collection, with delimeters (open, 
in-between, close).

This is very lightweight, and a constraint is that open != in-between 
and close != in-between (so that you can read back an array).

You'll write things like:

std::vector<int> v;
v.push_back(1); v.push_back(3); v.push_back(4);

std::cout << write(v, "[ %, % ]"); // [ 1, 3, 4 ]
std::cin >> read(v, "[ %, % ]"); // read back
std::cout << write(v, "[ %\n% ]"); // [ 1\n3\n4 ]

A facility for escaping strings will also be needed.

I will make some time later this week, and come up with a very 
lightweight version of this.
(in the meanwhile, I'll also look at Rozental's implementation - maybe 
that's all we need)

And just to make it clear once again:
The "Output Formatters" library *should not* provide Input facilities 
(Reece, please take note!)

> 
> 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.
> 

It's so funny, during reviews, everyone comes up with his own better 
version of the reviewed library.

Reece's lib has been in the sand-box for so long, and nobody said anything.

I will talk to Reece, so that he'll update the docs showing how he wants 
to redesign his lib. If there's (negative) feedback, he'll update.

If I were Reece, I'd go with a semi-highly-customizable lib at first, 
and once it's accepted, add more to it.

And if 3 months is unrealistic, we'll postpone.

Best,
John

-- 
John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons (work for MessageBox too!)
    + tab dialogs, hyper links, lite html