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