Re: Classes for fundamental types, renaming GtkArg

[Marius Vollmer <mvo zagadka ping de>]

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?

> well, your voice has certainly been noted, but i'm still far from
> being convinced that we should cause major source incompatibilities,
> just for a change that makes a certain sructure name nicer or more
> descriptive.

That's a valid position and you have convinced me that pushing for
renaming GtkArg leads nowhere, but at least I have tried. ;-)

My bigger concern is actually the `object argument' thing.  That name
still doesn't make sense to me.

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