Joel de Guzman wrote:
That said, I will discuss it with Hartmut and with the Spirit users. Let's see how it goes.
Thanks.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library.
It should, IMO.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
These tasks are the opposite. I don't see why they should be mixed in a single library.
Traditionally, that's true. Have you seen a formal language like EBNF describe generation yet? But if you think outside the box, these really *are* two sides of the same coin.
Should Boost.Serialization should be broken into two libraries, for example? Perhaps, but those sub-libraries are under Serialization. Ditto for IOStreams.
You may have a point here, although I regard parsing and formatting as more disconnected tasks than serialization and deserialization. I guess, that's because I often do one without the other. However, that doesn't change my opinion regarding the library naming or reviewing sub-libraries.