|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-21 10:23:31
In message <0011211201440K.17834_at_[hidden]>, Jose
Orlando Pereira <jop_at_[hidden]> writes
>I'll try to paint the big picture: As I see it, at the higher level,
>XTL and current version of persistence are very similar. For instance:
>
> class X {
> int i, j;
> list<int> l;
>
> template<class Desc>
> void describe(Desc & descriptor) {
> descriptor & i & j & l;
> }
> }
>
>versus:
>
> class X {
> int i, j;
> list<int> l;
>
> template <class Stream>
> void composite(Stream& stream) {
> stream.simple(i).simple(j).simple(l);
> }
> }
>
>However, I prefer the more verbose version in XTL. The reasons
>are:
>
> - its less obsfuscated (warning: personal taste!)
> - is not ambiguous (what is the interpretation of i & j
> when both i & j are integers? this is the same issue as
> in << overloading for streams, so it must have been
> solved... Anyone preceisely remembers operator precedence? ;)
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.
> - cleanly allows for type annotations.
>
>Annotating types is necessary as in C++ (due to its C legacy)
>some types have more than one semantics.
[...]
>Of course, this could also be accomodated in persistence's syntax by
>defining wrapper classes.
I would personally prefer this, esp if a stream-based syntax were used:
descriptor << optional(i) << required(j);
Kevlin
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
Curbralan Limited mobile: +44 7801 073 508
mailto:kevlin_at_[hidden] fax: +44 870 052 2289
http://www.curbralan.com
____________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk