Re: [guppi-list] Re: Stabilizing the DataSet interface?

["Asger K. Alstrup Nielsen" <alstrup diku dk>]

> I haven't really sunk my teeth into this code yet, so I'm really
> speaking from ignorance here, but just two quick questions:
> 
> (1) Is there any way we can use locales to make things like the
>     RealConverter automatically do the right thing, i18n-wise?
>     (I don't know the first things about locales or how they work...)

We can use locales to do some of it, but the problem is that
the international settings is only part of the problem.  There
are other issues such as thousand delimiters, scientific notation,
number of significant digits and more (and this is just for numbers).

Also, if we use locales to solve the problem, things get more complicated,
because it should be possible to have one DataSet using "." for decimal
punctuation, and another use "," at the same time.  If we were using
locales, we would have to change the locale back and forth all the
time, and this is difficult in a threaded setting.  It's problematic 
to have state information in the C library..

Therefor, I think it's easiest to solve this problem without using
the C locales.  After all, the support in the C library is limited,
so it's not much extra work.

> (2) Is there a nice way that we could make the use of the
>     DataConverter framework optional for future DataSets.  (Primitive,
>     half-formed ideas about some of the currently-unimplemented
>     DataSets are rattling around in my brain, and I think that there
>     may be some cases where the DataConverter is overkill.  On the
>     other hand, I do see how some of the expanded functionality of the
>     DataConverter could be useful for really smart and flexible ascii
>     imports and other stuff... so only take this question half-seriously.)

The DataConverter is optional in the sense that it can be a dummy
DataConverter, like the base class is.  You don't need to define
a new one for each type if there is no need.
It's up to each DataSet to chose a DataConverter.  If a particular
DataSet only deals with one string representation of the values,
there is no need for a customized version, and the default one
will be adequate.

So the bloat is restricted to the two virtual methods for accessing the
DataConverter.  (I'm not sure we inherit a useful default DataConverter
as it is now, but I'll change it to be so.)

Greets,

Asger