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

From: Beman Dawes (beman_at_[hidden])
Date: 2000-11-20 14:06:34

At 08:46 PM 11/19/2000 +0100, Jens Maurer wrote:

 >Beman Dawes wrote:
 >> 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 believe there is not much difference in the overall approach.  I wanted
 >to get my update out so I don't sit on a bunch of changes.  To have some
 >fun, I also wanted to see how a unified describe() for C-style structs
 >would look like.  Look at the cute operator-overloading syntax
 >(proposals for a better operator than & accepted)  :-)

Yes, it certainly is clever.  For those of you who haven't looked at it, 
structs can be described like this:

      descriptor & license_number & color & length;

Where license_number, color, and length are the members.

But I'm a little worried about the Second-System Effect (first described by 
Brooks in "the mythical man-month".)  In other words, tossing in every cute 
feature results in feature bloat.

 >The problem with XLT at the moment is that it seems to provide the
 >portable binary representation (GIOP, XDR), but its support for a text
 >format is lacking.  Additionally, I can use a mem_buffer, but I
 >cannot use iostreams.
 >
 >As far as I understand it, these items would be main obstacles for
 >Beman's usage scenario.

Yes, those issues would have to be dealt before XLT would meet the needs as 
I understand them.

 >> (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.)
 >
 >This is the same with me:  I am obviously biased as well :-)
 >
 >Advantages of XLT are:
 > - Handles pointers to objects (also has an option for handling
 >circular data structures)
 > - Handles fixed-sized C-style arrays

Is there a design impediment to you supporting those features?  But in any 
case they seem less important than getting nested (HTML, etc.) formats 
working.

 >The disadvantages of both approaches are that you need lots of
 >template instantiation depth and it takes quite a while to
 >compile.

Another argument for not getting too carried away with interesting but 
impractical designs.  We have to keep in mind that a persistence library 
exists to serve a practical need, not a demonstration of template magic. 
(That isn't meant as a criticism; it's just a comment.)

 >To make my text support really flexible enough for XML or HTML
 >would need a lot more effort in both approaches, though.

The boost library (particularly version 1) doesn't have to actually include 
readers and writers for many different formats, just so long as the design 
supports them so that they can be added either in version 1.1, or by a 
user.

Anyhow, I'll try to look at persistence2 in more detail later today or 
tomorrow.  Keep up the good work!

Thanks,

--Beman