----- Original Message ----- From: "Jeremy Maitin-Shepard" <jbms@cmu.edu> To: <boost@lists.boost.org> Sent: Wednesday, June 20, 2007 8:33 AM Subject: Re: [boost] [rfc] I/O Library Design
Andrey Semashev <andysem@mail.ru> writes:
[snip]
From my point of view we have touched two problems in the discussion: the ability to easy and efficiently format things into text or octet strings and internationalization support.
With you so far, but there is so much more! ;-) What if a developer wants to print an unsigned long as an IP host address (dotted notation), within some debug output? What if that same developer wants to allow for the input of some IP address other than the printed default? What if a developer wants to print a vector<site_security_profile> as a readable table (headings, tabstops...), within some logging system? What if the same developer wants to allow for runtime input of the security profiles, beyond the content of a file with appropriately formatted defaults? What if a developer is initializing a UI report control with the contents of map<SKU,shelf_item>? And the final product is to be rolled out through a franchise spanning most of Europe? Dont mean to be flippant with these examples. They are just supposed to shine the light around; drag some significant parties into the discussion, i.e. would resulting libraries be targeted at developers and their debug requirements or developers and their pan-language UI requirements? A functional breakdown of the above might look like; 1. Character stream with embedded runtime values * default format control on a per-C++ type basis * format overrides (unsigned long as dotted IP) * user-defined format for user-defined types * user-defined input-text-to-type-instance conversion 2.Character stream with embedded runtime layout control * default layout control for tabulation of STL containers (no headers, 8 space tabstops) * layout overrides (specific headers and tabstops) * user-defined layouts for user-defined types (e.g. labels, line-per-type-member) * navigation, selection and text input of layouts 3. Runtime construction of i8n display information * too big to start listing This is just a sequential listing; the order is not intended to be significant. The grouping relates to the examples rather than a set of suggested proposals. I suspect there is a matrix of end-user system requirements and potential software technologies. Developers need to be able to declare at compile-time whether the application debug stream has user-defined types and/or unicoding requirements. Does the UI need to speak anything other than Cantonese (and is that the developers first language?). With that ability to "cook up" the different streams the potential arguments over whether unicoding should be present within a debug stream evaporates. It becomes a per-application decision. As further input to this thread; I have recently done a lot of work in the areas of serialization and also rendering that same information in different UIs. There is an intriguing amount of overlap between what serialization does and what debug/logging/UI streams need to do. While I wont go as far as saying that application streams should exist over serialization technology (hmmmm) there might be borrowed techniques? Cheers.