Re: TreeView::append_column_numeric() format?

[pks timing com]

Carl Nygard writes:
 > 
 > How about taking a step back and making it more generic?
 > template <typename Trans>
 > append_column_translated(modelcolumn, const Trans& translator =
 > Trans());

that's what I was suggesting, without the functor prototype
you provided.  The Convert* functions you mentioned are kin
to the operator() implementations I mentioned:

 > template <typename T>
 > struct NumericTranslatorSample {
 > NumericTranslatorSample(int precision = 0) : _prec(precision) {}
 >     string ConvertToRep(const T& val) {
 > 	stringstream s;
 > 	s << setw(_prec) << val << ends;
 > 	return s.str();
 >     }
 >     T ConvertFromRep(const string& str) {
 > 	stringstream s(str);
 > 	T val;
 > 	s >> setw(_prec) >> val;
 > 	return val;
 >     }
 >     int _prec;
 > };

 > TreeModelColumn<MyType> whatever

And MyType (or AnyType) is where I was headed with the string
example (any old type not just numeric ones).  Looks like we have
a quite similar vision.

On Tue, 2004-11-23 at 04:23, Murray Cumming wrote:
> 
> So far I think:
> 1. I don't think it would be a good idea to add a whole generic numeric
> formatting framework to gtkmm just for use by this convenience method.

I don't believe it would have to be a "framework" within gtkmm.  It would
be a place where the end user can put a functor to work.  The convenience
function you mentioned could be implemented in terms of one, along with
no, or a hundred others ...

On Tue, 2004-11-23 at 04:23, Murray Cumming wrote:
> 
> 2. If this was not used in any other part of the API, then people would
> never become familiar with it, so it would make this method far too
> difficult to use.

This is a good point.

I didn't hesitate to suggest functors or even template specialization
because the current model/store/view paradigm already employs templates,
likely much more so in the implementation than what is exposed in the
api.

To create a store one has to derive model column record, to
append_column() (at least in the examples) the column record, rather
then store is used again.  An optional string conversion functor
which has to implement the Convert() functions Carl suggests doesn't
seem to complicate things that much.  And the "convenience function"
which started this thread, creating "the (one of) convenience functor",
is just an implementation thereof.

> 3. Providing a sigc::slot, as we already do with set_cell_data_func() is
> probably easier than deriving and overriding virtual functions.

since the append_column() parameter to the functor would be templated,
the functor would only have to implement the conversion routines ...
nothing would have to be derived ...  that's what I was referring to
when I said "anyting std::transform()" would accept.  Notice that
Carl's example doesn't subclass anything either :)

I'll try to cook up implementation this weekend.  This has been most
interesting discussion.  Thank you both.