Re: [boost] Re: generic polyvalent input/output ['pickle']

From: Beman Dawes (beman_at_[hidden])
Date: 2000-11-17 17:32:36

At 09:48 PM 11/17/2000 +0100, Jens Maurer wrote:

 >Beman Dawes wrote:
 >>    save<Writer, container parms...>(writer, container)
 >> save<Writer, ForwardIterator>(writer, first, last)
 >> save<Writer,T>(writer, object)
 >
 >>    * Overloading of the name "save" at three different levels
 >>      is confusing. Rename them?
 >
 >The point is that these are not really three different levels:
 >A container is just another object, and an element of a
 >container may in turn be yet another container etc.
 >
 >So the first and third level in the above list have to be
 >named the same.  I could rename the second level to save_sequence()
 >or so, ok.

Not a big deal, but renaming it might make the package a bit easier to 
understand.

 >
 >Further thoughts about XTL vs persistence.hpp:
 >
 > - I like the unified reading/writing approach of XTL, and I think
 >I am going remodel my stuff for that.  Describing user-defined
 >composite objects just once for e.g. easy C-style structs saves half
 >of the work if you don't have to do it for both reading and writing.
 >A user should always have the option to provide separate reading
 >and writing strategies for complex objects such as containers, though.
 >
 > - In addition to optional unified reading/writing at the object 
structure
 >description level, it is also nice to have reading and writing
 >unified for the output format description level.  For example, string
 >delimiters or begin/end markers for sequences should be the same
 >for reading and writing.  Thinking a bit further about it, the reading
 >side should probably not have a "this is the delimiter" style
 >function, but an "eat the delimiter" interface to allow for some
 >fuzz factor when reading.  (regex may come in handy for specific
 >formats.)

"Eat the delimiter" would help in some of the work I do.  The inputs (for 
tables that get loaded into associative containers) are in fact hand 
created and maintained by text editors, or are output from unrelated 
programs (like commercial DBMS, spreadsheet, or HTML software).  Thus 
allowing for fuzz would eliminate the need to provide custom readers just 
because of the fuzz.

But Jens, what about the big picture?  Are you convinced your overall 
approach is better that XLT?  Do you want to continue developing yours?

(I'm personally trying to keep my mind open until I understand XLT better 
than I do now.  Obviously I'm biased toward your approach due to 
familiarity, but I want to give XLT at least a chance and not reject it 
just because Not Invented Here.)

--Beman