Robert Ramey wrote:
Just to speculate on an imaginary example - please don't treat this as a serious proposal which I have to defend. Suppose someone comes along and looks at the xml_archive. He says wow - now that is way cool - But its really not done. What I need is to create an xml schema along with with my xml_archive so i can use my xml wizebang tool to browse and maybe edit my archive!. [...]
[...]
Here is the key point. I'm not really concerned about specifically about save_array.
The save_array optimization is one example of any number of enhancements and/or extentions that people might want to make. But it is not the only example. We can't go mixing every great idea into the core library without running into an intractible scalabilty problem.
True. But there is a fundamental difference between your enhanced archive examples and array serialization. One function of the library is to act as a mediator between programmers that write serialization functions for their types and programmers who implement archives. The library provides a common language so that these two groups of programmers can communicate without ever having to coordinate their efforts. When the author of X that has two fields x and y wants to serialize it into _any_ archive, he just "says" save(x) and save(y) to the archive. However, the author of Y that contains an array currently can't just say save_array(a) to the archive, because save_array is not part of the current vocabulary. He needs to say save(a[0]), save(a[1]), ..., save(a[n-1]). This works, but it makes it needlessly complicated for the archive to detect that it is being fed an array, rather than a sequence of ordinary save calls. In contrast, the "someone might want to do..." enhanced archive examples do not involve communication between these two groups of programmers. The programmer of the archive just decides to implement a specific format and that's it.