Re: Abstract string properties with getter/setter functions

[Raffaele Sandrini <raffaele sandrini ch>]

Ok i see there is need to clarify things.

On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote:
> On Wed, 19 Sep 2007, Raffaele Sandrini wrote:
> 
> > Hi there,
> >
> > While implementing abstract properties in Vala we encountered a problem
> > regarding string properties with getter and setter functions:
> >
> > public interface Test.MyIface {
> > 	public abstract string text { get; }
> > }
> >
> > A getter function of an abstract string property looks like:
> > char* test_my_iface_get_text (TestMyIface* self) {
> >        char* value;
> >        g_object_get (G_OBJECT (self), "text", &value, NULL);
> >        return value;
> > }
> >
> > Property accessors in Vala always return weak references. This leads to
> > a memory leak in the calling function of the getter.
> 
> i'm not sure what you mean with weak/strong references when it
> comes to strings. in C, pointers can be handed out which point to
> 0-terminated char arrays that represent strings. there's on reference
> counting for strings in C as there is in C++. per convention,
> for glib/gtk programs, some such string pointers must be g_free()-ed once.

With strong/weak references is talk about ownership. If some code needs
ownership over a string it will dup the string.

> 
> callers of getters have to free the returned string in C.
> for glib/gtk programs, if the caller doesn't need to free the string,
> the return value should be G_CONST_RETURN gchar*.

That's right since the getters do not claim ownership they do not need
to free the strings. The problem is the caller assumes a weak reference
and will dup it if it needs ownership.
The point here is that we are talking about *abstract* properties i.e. i
do not know whether the implementation uses a static string or not. I
have to call g_object_get whether i want to or not.

> 
> > We want property accessors to return weak references so just redefine
> > the accessors to return a strong reference is only a last-resort-option.
> 
> requesting that all string return types should be const char* is technically
> not possible, because some strings need to be constructed in getters.
> 
> people who don't want to deal with these memory allocation issues (const
> strings vs. caller-needs-to-free strings) should stay away from C, maybe
> even C++, and use python, java, scheme, other-garbage-collected languages.

Vala needs to deal with this issues to enable users who do not want to
deal with it an easy life.

> 
> > Since we do not see a way around this (yet) and we could not find an
> > example with strings in another project. I'm asking here if there is a
> > nice way around this.
> 
> i'm really not sure i understand your problem here...

We need a way to steal the string from the property i.e. to make sure
its not a copy of the original.

> 
> > BTW: There are equal issues with properties returning objects only there
> > you can add a hack into the getter unrefing the object before returning
> > it. This is not applicable with strings.
> 
> this is not applicable with objects. as soon as you called unref(obj),
> the object will be destructed and gone, you can't hand it on any further,
> "obj" will point to freed memory.
> in some rare cases and if you're lucky, the object might stay around
> a little longer because someone else could coincidentally hold another
> reference. but this can't be relied upon.
> a well formed getter implementation might do:
>    return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL));
> once you g_object_unref() this return value, it'll be instantly vaporized with
> a crushing noise (if you hooked up pulseaudio via destruction emission hooks ;)

You can check the ref count first. Take a look at the GtkFileChooser interface
there this hack is used several times. (and annotated as such)

All we need from you is either a solution or the statement that this is
not possible with gobject properties ;).

Forgot to post the bug against Vala: http://bugzilla.gnome.org/show_bug.cgi?id=472904

Hope things are more clear now.

cheers,
Raffaele