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

[Jose Orlando Pereira <jop@di.uminho.pt>]

On Tuesday 21 November 2000 15:23, Kevlin Henney wrote:
>
> I hate to point out the obvious -- and perhaps I'm missing something
> fundamental -- but is there a reason that operator<< is not being used
> in either approach? It seems to fit with the accepted streaming
> semantics, populating a descriptor with the data member. As for
> disambiguation, there is nothing to disambiguate because of operator
> chaining.
>
> I would personally prefer this, esp if a stream-based syntax were used:
>
>         descriptor << optional(i) << required(j);

I considered it, but as the same method is in XTL used for
both reading and writing, I was not able to decide wether to use
<< or >>. :-) As I see such methods as generic descritpions
of the class and not only as an IO mechanism, using a syntax
that has a strong connection to IO seemed awkward. 

My choice also has historical reasons, as when I started XTL
the only compiler for Linux was gcc 2.7 and had limited 
support for template specialization. In that situation,
many data types that can now be described as simple()
had to be described more precisely. Notice that this
is still true for many compilers (e.g. VC, for which I
keep getting pacthes to "downgrade" XTL to what it was
years ago).

In addition, when separate descriptions are used for input and
output (again, it is more generic than that, it is for "construction"
and "destruction", having similarities to what people in the
generic funtional programming community call catamorphisms and
anamorphisms) neither makes sense, and supporting both seems
too much clutter for no visible gain.

As this might not have been clear in my previsou message, here
it goes again. We have two distinct problems to solve:

 - generic traversal of data structures, for which XTL proposes
   the composite/objio interface;

 - using the traversal for IO which requires thinking about
   formats and storage, for which XTL proposes "format filters"
   supportin XDR, GIOP, and text (although currently readonly
   because I was to lazy to forward port it to the current version)
   and "buffer adapters" for which XTL proposes a minimalist 
   memory buffer for maximum performace but supports writing
   to C++ streams (I've been sent a patch for this today that
   I've just posted on xtl.sourceforge.net).

-- 
Jose Orlando Pereira
* mailto:jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *