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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-25 04:53:31

John Torjo wrote:

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

How? The difference between:

  locale::global(locale(), new vector_io_facet(.......))

and

  cout << vector_io_format(......)

is in interface, not implementation.

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

It's too large, for starters.

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

Hmm... are you about to write some code? Isn't this a bit contrary to review
manager role -- he's supposed to be non involved in the development of the
library that's being reviewed.

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

Now, I don't want to start a revolution, and I don't have anything against
you in personal, but there are some points:

1. The library is rejected. Only another review can make it enter Boost.
2. We don't have a rule that re-review must be managed by the same person
who managed the first review. We don't have any "library won't be
re-reviewed unless do change this and that" resolution. So I don't think
it's OK to require Reece to remove input facilities. I don't think input
facilities caused any big problems, and we can't be sure they cause
problems in a redesigned library.
3. It's a bit problematic that you start to take part in design
discussion/development.

And just for a record: I count 4 "no" votes for input (including yours) and
2 "yes", which means that 1/3 of all the users want this.

 >> 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 was using an alternative library from the same sandbox, for example. I'm
not sure if Reece used to post a periodic preliminary versions.

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

Ohh... what's "semi-highly-customizable"? The "highly-customizable" is vague
itself, not to mention "semi" ;-)

- Volodya