Re: Exporting the Gtk+ object system to interpreters [was: no_marshall signals and GtkTypeInfo]

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:

> Yes, I've run into the same problem with Gtk/Perl, of course.

Yup, I suspected as much.  I know that Gtk/Perl has already some class
stuff going; shame on me that I didn't investigate how you did it.
But it seems that I hit the nail pretty well on the top, judging from
your comments.  I planned to put forward a more carefully thought out
proposal, but now is not the time.  Anyway, if you have some specific
requirements...

> This (or rather the underlying mechanism) would be
> appreciated. (Note that there is currently no way to fake it, as
> "class functions" don't have any sort of "data".)

Right.  You are not happy with the exposed interface? (because you say
"or rather the underlying mechanism".)

> > I see the creation of a signal without a default marshaller as a
> > conscious act of saying: "Look, as much as I like to, I just *can't*
> > give you a default marshaller.  I know that C handlers with a static
> > interface can't connect to this signal, but I'm willing to live with
> > that." [...]
>
> This of course hits Gtk/Perl as hard as it hits anything else. The basic
> problem is that C has no ability to construct functions at run-time. (I
> believe there is one or two libraries out there that attempt to solve
> this, but they are by definition not portable. Some day this will be worth
> considering, but not just yet.)

Agreed.

> I quite like the idea of making Gtk fully understand that a signal can be
> missing the C marshaller, and thus cannot be invoked directly from
> compiled C code. 
> 
> (Some method of providing a marshaller at a later time might make sense. 
> If compiled C code is added to the running code, it is logical that a
> marshaller could be constructed and added at that time.

Yes, that's a better way of saying what I wanted to get over in my
last post.