Re: GParamSpec further funcs

[muppet <scott asofyet org>]

On Jul 13, 2008, at 12:04 PM, Torsten Schoenfeld wrote:

> As you note in your ChangeLog entry (thanks for writing it!), this  
> change is
> not quite backwards compatible.  gperl_sv_from_value is really not  
> handling
> booleans correctly: it's treating them as integers with newSViv  
> whereas it
> should use boolSV, in my opinion.  boolSV is what the gboolean  
> typemap ends up
> using.  But it's too late to change gperl_sv_from_value.
>
> So I think the old get_default_value for booleans should stay, for  
> backwards
> compatibility and because it's actually more correct.
>
> muppet?

The old setup works by duck typing from the perl level.  By using  
g_param_set_default_value() to access the default value, you're using  
the polymorphic function pointers down in C code.

What would be broken by changing newSViv(boolval) to boolSV(boolval) ?

     if ($obj->get ('boolparm') == '') { # false is empty string!

Quite frankly, i see this as about as useful as doing

     bool foo = some_thing ();
     bool bar = some_other_thing ();
     if (foo == true && bar == true) {

in C to get "better readability" ...  it's not actually more readable  
-- it's non-idiomatic, and creates more code, and makes you  
susceptible to breakage if some_thing() starts returning more than  
just 0 and 1.

But, somebody probably has that code out there, because not everyone  
has learned by hard knocks that such coding styles are bad.  What can  
we do?  Use magical blessed Bool objects with overloaded operators?   
While it might be a fun hack, that's heavy overengineering.  So,  
changing gperl_sv_from_value() to use boolSV() is likely a  
compatibility break and therefore a non-starter.


By changing most of the stuff to use g_param_spec_set_default() for  
most but explicit get_default_value()s for the rest, we have a rather  
strange mix of duck typing and polymorphism.  This is a rarely-used  
back corner of the API, but still not worth creating something with so  
many oddities.


I'd say, then, that adding value_validate() and set_default() is a  
fine idea.  Since we try to hide GValue from the perl API, replacing  
it with normal scalars, g_param_values_cmp() should be left out in  
favor of gperl_sv_from_value() and the normal perl-level operators.   
And, don't change the get_default_value() mess to retain compatibility.


Hey, take heart -- gtk+ 3.0 is now not that far away (next year!), and  
we'll get a chance to clean up all this sort of mess with a new Gtk3  
namespace.  Just make sure we write down all these things so they  
don't get lost.

http://blogs.gnome.org/lucasr/2008/07/10/gnome-30/
http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf


> > Ah, that'll be a combination of cut and paste and me having
> > `indent-tabs' off normally.  I've yet to find an emacs setup that  
> > works
> > decently for xs.  I tend to use cc-mode with some settings, and  
> > then get
> > annoyed when it indents wrong, and then switch to text-mode or pod- 
> > mode
> > for the doc bits :-(
>
> I have the same problems.  Newer emacsen automatically use ld-script- 
> mode for
> *.xs files which is not that bad for indention but which lacks syntax
> highlighting completely.  There's an xs-mode.el on the emacs  
> wiki[1], but I
> haven't really tried it yet.

I'd like to introduce you poor fellows to my good friend vim...  he  
doesn't have these problems.  :-)


--
Zella, carrying a kite in a long plastic box:  It's like book!
Yvonne, carrying the wooden kite string spool:  It's like a wood!