Re: Glib-Perl - GSList in a signal callback?

[Brett Kosinski <brettk frodo dyn gno org>]

> > If you're curious, it's in gstmultidisksrc.c, involving the NEW_FILE
> > signal.  Basically, the signal parameter type is defined as
> > G_TYPE_POINTER, and the callbacks are expected to cast that to a
> > GSList to
> > work with it.
>
> yeow!  okay, that's just not a terribly safe thing to do, because now
> there is no way to determine the type of that pointer at runtime, even
> for paranoid runtime checks in a C app.  personally, i would log that
> as an API bug.

Hmm... yeah, I'd have to agree with that in this case.  Perhaps I'll
propose a new API to the developers and see how that flies. :)  A better
question is, what is the alternative...

> b) break the perl bindings' abstraction to support this stuff by
> offering a function to convert the pointer value into a list of strings.
>
> given that i can't think of a clean way to do a), it sounds like you're
> stuck with b).

Hmm... but how can I hook into the marshalling code to add this hack?

> you still would have to agree that the interpretation of that pointer
> is completely specific to this special case, and should thus be handled
> by a helper provided by the particular library (in this case, the Gst
> module).

I guess the question is, how else can you provide a list of values to a
callback (in the case of the possibility of just changing the API)?
AFAICT, there's no other way to do this, other than to encapsulate a list
of some sort (GSList, array, etc) in an object and provide wrapper
functions to access the underlying list... in a word, YUCK!  A better
question is why doesn't Glib already have a GSList object of some sort
already...

> have you found many more cases like this?  i took a brief look at the

Actually, this is, AFAIK, the only one (I had to go through the whole API
and change a bunch of G_TYPE_POINTER arguments to their specific types).

> python bindings in cvs, and they looked rather incomplete, but
> complained that some of the GstObject method names clashed with the
> GObject ones...  i ran into something like this with the treemodel in
> Gtk2, and got around it by prepending to @ISA instead of appending
> (gperl_prepend_isa, i believe).

*nod*  Yeah, I figured there'd be some decent way around this.  I'm still
very much in the early stages though, so I wasn't too concerned about it
yet. :)

Brett.