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

[Yu Feng <rainwoodman gmail com>]

On Sat, 2009-01-10 at 14:30 +0200, Andrew W. Nosenko wrote:
> 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? :-)
> 
My mail is off the topic. It is about applying Gobject in physic
research:

I am not sure if the GTK people intend to see a proliferation of GObject
to happen at all. But GObject can definitely do more than GTK. 

I have been trying to incorporate several physics research packages with
tools built on top of GLib, and also been writing a physics package with
GObject; so far so good.

In some sense, the dynamical type system in GObject is exactly what the
physics people struggled and failed to build with C++/Java and their
poor understanding of software. The huge overhead for creating Classes
in GObject also tend to reduce the number of classes therefore leads to
carefully thought, and clearer frameworks.

Unfortunately, most physics people don't even know GObject at all;
neither do I have sufficient influence to advertise GObject in the
community.


Yu