Re: Signals, GErrors and Introspection

[Colin Walters <walters verbum org>]

On Fri, Feb 18, 2011 at 6:19 PM, Andrea Bolognani <eof kiyuko org> wrote:
>
> The situation is, I have a GObject implementing an interpreter for the
> Brainfuck programming language; whenever the interpreter needs to interact
> with the user, it emits a signal (input-request or output-request) and lets
> the connected signal handler do the job in an application–specific way. If
> you want to poke around the code, you can grab it by cloning [1].

While I know there are some examples of GObject libraries using GError
in signals, I think it's a bad idea even without bindings being
involved, because signals are designed to allow multiple connections,
but that doesn't make sense in this situation even in C.

You can design the API so that a GError is a return value from a
callback, or design the API so that callers need to implement an
interface or subclass.

> From what I’ve seen, to make my code work seamlessy in Gjs the following
> things would need to be done:
>
>        * Add support for boxing a GError** into GValue
>        * Add support for a ERROR parameter type to glib-genmarshal
>        * Teach gjs how to convert a GError** to/from a JS value

I'd prefer we try harder to avoid using GError in signals than hack
this in.  This would be another case where we have to step outside the
GType system, which gets into pain.

Also not a big fan of introducing a totally different exception API.