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

[muppet <scott asofyet org>]

On Monday, May 26, 2003, at 12:39 AM, Brett Kosinski wrote:

> > do you have example code?
>
> Well, first, I must say I haven't actually *tested* this to see what
> happens.  But I'm pretty certain Glib-Perl won't do the right thing.
> The code exists in GStreamer and passes a GSList to a callback which
> contains a list of strings.  I'd provide the actual code, but I'm not 
> sure
> how useful that'd be.
>
> 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.

in trying to see how it was used, i couldn't find any documentation on 
the GstMultiDiskSrc in their API reference, and indeed it took me about 
twenty minutes of searching in cvsweb even to find the source file.

however, out of all my searching, it looks like this is not a terribly 
common thing.


given that there is no GType for GSList, it's obvious that you'll have 
to either:

a) somehow proxy the new-file callback, either by api indirection or by 
changing the api at the binding level, so that you can convert that 
GSList to a native perl list, or

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).

now, if you'll put up with me being a fussy ideological jerk about this 
for a moment, here's why i would really rather not supply the 
GSList-of-strings-to-perl-array conversion function in Glib-Perl 
itself.  a perl developer should never have to know that there's a 
difference between how perl represents lists and how GLib represents 
lists.  this particular callback is ill-behaved in the sense that it 
doesn't tell you what type the argument is; and even if you take the 
point of view that well, actually, they told us that it's a pointer, 
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).


have you found many more cases like this?  i took a brief look at the 
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).