Re: Second draft (was Re: defs files)

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 19 Jan 2000, Havoc Pennington wrote:
> 
> > - argument becomes "object-argument" or "parameter"
> 
> i'd rather not see "parameter" taken, since that may become the name of a
> new mechanism in 1.4.
 
New mechanisms called "properties" or "attributes" would be fine.
Please lets not repeat the "argument" fiasco and call something in 1.4
"parameters".
 
> On 19 Jan 2000, Havoc Pennington wrote:
> 
> > Karl Nelson <kenelson@ece.ucdavis.edu> writes: 
> > > Shouldn't the signal have the c-name of emitting function if 
> > > the signal is publically callable.  Having a signal
> > > and the emit definitions separate means the relationship
> > > is weak.  Since we prefer calls to be made to the emitting
> > > function rather then directly with gtk_signal_emit, because
> > > extra checking is done in the emit function.  
> > > 
> > > Defining them separately seems bad.  
> > 
> > Indeed, this is another thing I can't autogenerate though.
> > 
> > Can I propose a /*< emits signalname >*/ magic comment to go on the
> > line preceding any function that emits a signal? this could go in the
> > 1.2.x branch in CVS (even if a 1.2.7 is never released we can use the
> > CVS code for defs-generation).
> > 
> > I think the magic comments are the thing to add whenever we can't
> > autogenerate stuff. 
> 
> for one, i don't particularly understand why you need to know what signals
> get emitted by a certain function (there might be a bunch involved like with
> gtk_widget_show).

I agree. Whether a particular signal has an emit function or not is
not really the business of the language binding.

It's just a convention that there is a frequently a method with the
same name as the signal. But the correspondence is a matter for the
library documentation, and it would be legitimate to have the method
have a signature that is different from the signal callback signature.

Regards,
                                        Owen