From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-12-18 18:52:04
I have now fixed some of the issues relating to my library (like hte use of
throw() and double underscores), as well as making several updates.
Here is a list of points that I am considering with regard to evolving the
library. This is based on the latest sandbox version:
 format[$|list$|range$] -- sort out a consistent naming system; convert
this into a series of function aliases for formatob. E.g. formatlist( FI f,
FI l ) = formatob( range( f, l ), rangefmt());
[note]: VC7 and Borland have problems with a uniform formatlist name. Also,
using the formatob alias does not allow the following construct:
formatlist( f, l ).format( " -- " );
 replace the array and container outputters with range_output in
combination with range( ... ). This will have an inpact on the type
deduction system (which i am considering revising).
 how do we distinguish nary< 2 >, nary< 4 > and nary< 8 > in the output
 need to implement putval to complement getval (based on your e-mail) to
simplify and unify writing to nary types.
 It is now easy to extend the list of supported nary types by adding a
new getval overload. This is where I see the type deduction system evolving
-- is this possible? E.g. something along the lines of:
range_type gettype( std::slist< T, Alloc > * ); // slist support in type
This would make extending the supported types very easy.
 Change the naming of the formatting objects to reflect the addition for
input support. My current thinking is xxx_object, e.g.
 Changing the output method of a formatting object to "write" to be
consistent with the "read" method being added and to reflect serialization
-- this may make it easier to implement interoperable I/O over display and
Reece H Dunn
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk