Re: Second draft (was Re: defs files)

[Karl Nelson <kenelson ece ucdavis edu>]

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

The business of the language wrapper is should it provide a 
function to be equivalent to gtk_signal_emit_by_name(o,"foo",blah)
or is there already one.  

Please don't tell me that all signals are private.  I 
translated the gtk+ tutorial and have looked over testgtk+.  Every
time we have assumed that some signal shouldn't be emitted directly
from application code we find another case where it is.  

I personally don't see why you need a separate declaration for
gtk_buuton_clicked function and the GtkButton::clicked signal.

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

Remember that in some language bindings the signals and the 
functions share the same namespace and thus those evil
signals which take slightly different parameters than the 
emit function are unwrappable.   It is by convention that the
signal and emitting function are the same parameters so that
you know how to connect them.  Breaking this convention 
results in vast exceptions in the wrappers.  

(C++ has overloading, but you can't overload a function and
a value member to the same name.)

I think Havoc will agree with me that this info is vital
to the wrappers and that the convention that the signal have
the same parameters as the emitting function be enforced.

Thus I would propose that there be no function definition
at all for functions like gtk_button_clicked or gtk_widget_event.
Just declaring the signal and naming the function which should
be used to emit it is enough to generate both the signal and
the method.   

--Karl