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

[Kenneth Albanowski <kjahds kjahds com>]

On 8 Dec 1998, Marius Vollmer wrote:

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

Let's see... There are a number of little glitches, currently, including:

	No way of getting the object and class sizes of a type at
run-time, without compiling a of sizeof() invocations.

	The requirement of needing to know the number of signals that will
be used, during construction. (This is certainly excusable, it's just
mildly painful when combined with everything else.)

	Needing to construct the new object layout with class signals
manually, assuming that class signals are used. (I mean, using the class
size and arithmetic to lay out the subclass. This is perfectly workable
and reasonably portable, but feels messy.)

	The names of primitive types (int, string, etc.) have danced
around a bit, making variables a little difficult to construct.

Disregarding these, the only real problems at the moment are insufficient
details in signal arguments (no type for pass-by-reference), and the lack
of a "data" parameter for class signals. 

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

No, that interface should be fine. I just meant that I don't really care
what the interface is, as long as there is an interface, _and_ the
underlying mechanism to support it. Currently there is neither. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)