[boost] Re: Re:Re:Re: Output formatters: different approaches

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-10-04 03:27:36

> When comparing your code and the proposed library, I have two points.
>
> First, the proposed one has a lot of code to detect what kind of object is
> output, for getting its elements, and so on. This adds a lot of complexity
> and should be avoided -- by using serialization library to do the task.

Ok. But I am not sure serialization library as it is now could be used for
this purpose.

> Your implementation is indeed simple. But: it contains code which
iterators
> over elements of a vector. Should I define my_cool_vector, I'd have to
> define an overload that your code can use. I'd prefer to defining only
> overload for serialization library, and have the output library use that
> automatically.

Actually it's not exactly true. If you notice in a comment before
void decorate_elements( std::ostream& ostr, std::vector<T> const& c,
Decorator const& d )
I mention that it's actually supposed to be generic version that used for
any class that match Collection concept, something like:

enable_if<is_collection<T> >
void decorate_elements( std::ostream& ostr, T const& c, Decorator const& d )

> Another point about your implementation is that it does not distinguish
> between sequences/maps -- which might be desirable.

If you do want to distinguish you could do this with overloading like this

enable_if<is_assoc_collection<T> >
void decorate_elements( std::ostream& ostr, T const& c, Decorator const& d )

though I do not see an immediate need for this

> > Would you want something
> > like string format ("% | %") it could be easily added, though I question
> > its usability. It assumes a lot of things when applied to multivalue
> > container. As for reflection framework, I would be interested in generic
> > solution, but again not in a context of output formatting specifically
(I
> > may use it for this purpose, but not design it for this purpose).
>
> What I'm proposing is that output library use the *existing* mechanism,
> provided by the serialization library.

I supposed you want to reuse namely reflection abilities of it. I am not
quite sure existing mechanisms will allow you to supply convenient
interfaces for most basic (but mostly used) cased.

> - Volodya

Gennadiy.

P.S. I did not  have a chance yet to look on latest serialization library
implementation, but here:
http://article.gmane.org/gmane.comp.lib.boost.devel/78978
is my post dated somewhere in between two reviews, that describe traversing
framework that could be used by serialization lib implementation and by ant
other reflection need. I hope serialization library provide something like
that. In this case We may use it for generic output formatting.