Scott Woods wrote:
----- Original Message -----
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...
[snip]
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
Most of the above is about formatting and parsing data to/from text. IMHO, most of it is implementable via stream manipulators in the same manner. Thus I don't see much difference between 1 and 2 in this way.
3. Runtime construction of i8n display information * too big to start listing
That's the least covered area in the discussion. Unfortunately, I don't have much experience in supporting i18n since I mostly develop server applications, so I don't have much to say here. It would be good if someone more experienced than me could elaborate this field better.
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.
Agreed, users should be able to decide what they need and should not pay for what they don't need.
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?
Could be. In fact, I tend to think that streaming IO should implicitly support serialization as a form of formatting.