Re: GdaNumeric problems

[Murray Cumming <murrayc murrayc com>]

On Thu, 2011-09-08 at 15:42 +0200, Murray Cumming wrote:
> > > Actually, isn't this a general problem of boxed types inside
> GValues?
> > 
> > I'm not surprised at all that you are having such problems, it looks
> > certainly tricky. If you want to keep that API, I would add a
> minimal
> > test case to g-i+pygobject that reproduces it as the first step
> > towards solving it.
> 
> OK. I'll try to.

It would look something like this, where I've tried to reproduce it with
the string array in GThemedIcon (in gio):

class TestGDBusClient(unittest.TestCase):

    def get_boxed_type_in_a_value(self):
        icon = Gio.ThemedIcon.new('network-server')
        self.assertTrue(isinstance(icon, Gio.ThemedIcon))

        # This is actually a GValue containing G_TYPE_STRV, 
        # set via g_value_set_boxed().
        names = icon.get_property('names')
        return names
    
    def test_gvalue_with_boxedtype(self):
        value = self.get_boxed_type_in_a_value()
        print type(value)
        print value[0]


However, I guess that pygobject knows how to handle string arrays in
GValue. I think this would fail if the GValue contained a GdaNumeric,
which pygobject (presumably) doesn't know that it should copy.

I'm currently working around this by making my function return
somegdanumeric.number (a string) instead of somegdanumeric, allowing the
parent somegdanumeric to be freed after the function returns.

> > In the process of writing the test case you may discover it's
> something else :)
> > 
> > > Boxed Types are not reference-counted, and you wouldn't want to
> copy
> > > them just because a parent GValue's reference was increased.
> > 
> > Actually, many boxed types are refcounted, with _copy increffing and
> > _free unreffing.
> 
> But there's no way to know that they are reference-counts, I think. To
> the generic boxed-type registration API, they are just copy and free
> functions. 
-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com