Re: Classes for fundamental types, renaming GtkArg

[Tim Janik <timj gtk org>]

On 28 Aug 1998, Marius Vollmer wrote:

> Tim Janik <timj@gtk.org> writes:
> 
> > > I wouldn't mind if the "signal" argument of GtkObject goes away,
> > > as it would clear up a potential trouble spot.
> > 
> > what is the potential "trouble" spot here?
> 
> The interface to `object arguments' is a classical setter/getter
> interfacw.  The handlers of a signal are actually a list.  What
> happens when you set a handler twice?  How do you remove a signal
> handler with the object argument functions?

you certainly can't adress the handler by its id, if you connect it
through the argument mechanism, but you can still diconnect or block
the handler through its data pointer or the function adress.
if you need the handler id, the argument system is certainly the wrong
way to connect a signal and you should use gtk_signal_connect* explicitely,
but then again, the handler id is only rarely needed for normal gtk programming.

> > the object arguments do certainly more than that, they export significant
> > portions of a widget's API in a *genric* way. the actuall goal is to 
> > approva a point where a widget builder and even source bindings can
> > access *any* widget in a generic way, without implementing special
> > knowledge for any of them.
> 
> That's a noble goal.  But `argument' is not the name for it.  The
> terms would be `field', `data member', `attribute', `slot', `method',
> `member function', `virtual function', `accessor', `setter', `getter'.
> 
> > > So, even if we do not rename GtkArg to GtkValue, and all the various
> > > *_arg functions to *_attr (which I could understand very well), we
> > > should at least not call the things `object arguments' in the docs.
> > 
> > well, this would be questionable and should at least be reasonably
> > explained.
> 
> I don't think it is at all difficult to explain it.  The docs
> currently use "option", btw.
> 
> 

---
ciaoTJ