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

[muppet <scott asofyet org>]

On Monday, May 26, 2003, at 11:37 AM, Brett Kosinski wrote:

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

as a stopgap (as mentioned below, because for some reason i answered 
this from bottom up), just a boxed wrapper would work:

  GType gst_source_list_get_type ();
  typedef GstSourceList GSList;

not pretty, of course, but functional.  you could also use a string 
vector instead of GSList, and still have the type id associated with it 
so you'd know what it is and how to use it.


> > 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?

well, that's why this idea is so dirty --- you don't.

$src->signal_connect (new_file => sub {
               my ($object, $thing, $data) = @_;
               my @list = hackish_list_conversion_function ($thing);
               ### ^^^^^^ this is the hack ^^^^^^^^
               1;
               }, $data);

because i really can't think of another way.

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

since there's no type information for GLists, you'd have to create a 
small type wrapper, probably a boxed type.  it's not much work at all, 
and is quite often done for little special cases.  unfortunately, since 
this is a signal you'd have to change the gtype at the time of the 
signal's creation, which means an API change.

i can't say why GLib doesn't have a GType for lists, but i can imagine 
it wouldn't be very clean --- you'd have to have the GType for the list 
itself, and then another for the items *in* the list.  and since the 
list can hold *anything*....