Re: gparamspecs.c param_double_validate() doesn't support NaN/Inf?

["Andrew W. Nosenko" <andrew w nosenko gmail com>]

On Sat, Jan 10, 2009 at 2:06 PM, Brian J. Tarricone <bjt23 cornell edu> wrote:
> On Sat, 10 Jan 2009 13:42:31 +0200 Andrew W. Nosenko wrote:
>
>> First at all, could you provide any real-world example, where min/max
>> restriction on GParamSpec could be usefull?  The reason is simple:
>> when validation fails, the application has no way to know about it
>> and, therefore, to do anything usefull.  There just no interface for
>> such things, like "validation-fails-callback".  As consequence, any
>> validation should be done at the application level, before bringing
>> GObject/GParamSpec/GValue/etc machinery into game.  Hence, I hard to
>> imagine any usefull example of using restrcted GParamSpecs...
>
> Then you really just aren't imagining hard enough.  If you look at the
> gdk/gtk sources, there are quite a few GObject properties that use
> GParamSpecDouble that restricts the min/max value a property can have.
> For example, think of a progress bar that uses a double to indicate
> the percent full: 0.0 is 0%, 1.0 is 100%.  Any value outside that
> range is invalid.

I know about that.  But how it usefull?  What you can to do with it?
Yes, for progressbar it resulted just for some different rendering
that has nothing but visual effect.  You could to don't use restricted
paramespec but just silently CLAMP(), for example, without any harm.
Even if you do not do any validation, the result would be the same:
just a visual effects, possible ugly, but have nothing with the core
functionality.

In contrast, I say about about core functionality (application's
results, not application's appearance).  If you calculate distance
based on coordinates, for example, would you entrust validation of the
coords (latitude/longitude) to the something (GValue/GparamSpec in out
case) that silently alters value or brings it into undefined (in sense
implementation-defined and undocumented) state?

Please understand, while GObject was born from GTK+, I would to see it
as on generic-purpose C-based object system, not as on GTK+-oriented
underlying library...  And tasks that should be able to be solved
using GObjects are far more wider than just GUI and presentation...
May be it just my dreams that has nothing with Glib developer's
targets, but...  Can I dream? :-)

-- 
Andrew W. Nosenko <andrew w nosenko gmail com>