Re: [gtk-list] Re: an additional argument flag

[Kenneth Albanowski <kjahds kjahds com>]

On 23 Feb 1998, Tero Pulkkinen wrote:

> Kenneth Albanowski <kjahds@kjahds.com> writes:
> > Have you found some way of deal with class signals (or whatever you want
> > to call the signal slots that are held in the class object) in a
> > reasonable manner? Then again, C++ isn't an interpreter, so you won't have
> > many of the difficulties I ran into with Perl. 
> 
> What kind of problems you ran into? Explain more details:.

First of all, constructing a new type from an interpreter is a bit
tedious, since you need to know the size of the ancestors object and class
types -- this information is not directly accessible, without compiling
special purpose code. Next, you must know all the signals that will be
added to a class when the class is created (which is fairly trivial) and
calculate where the signal variable will be in the new class object -- all
of which is extremely tedious. 

Next, the class signals themselves don't participate in the usual signal
marhsalling schema. They are only a single function pointer, without a
gpointer "data" argument. Raw functions pointers are very hard to
manipulate from an interpreter. 

> I thought it would be even easier with dynamically types language where
> you dont need to care much about getting type checks to compile time.

Actually, _because_ it is a dynamic language, I care far more about type
checks then the C code does. My module goes to extreme lengths to figure
out exactly what sort of data it is dealing with in all calls.

This is made more difficult by the fact that I can't create an arbitrary
set of callback functions: I need to make one C function serve multiple
Perl callbacks. Thus a "data" argument is crucial.

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