Re: g_object_[dis]connect_valist

[Tim Janik <timj gtk org>]

owen> They are exceedingly esoteric C convenience functions...

i agree with owen here, they keyword is "C convenience" so these functions
shouldn't be glued by LBs, neither get wrapped by derived objects.
just as you shouldn't wrap g_signal_* functions.


On Mon, 30 Jul 2001, Eric Lemings wrote:

> Owen Taylor wrote:
> 
> > Why would you want to write a wrapper around these functions?
> 
> Why are the g_object_[gs]et_valist functions used for?  Whatever it is, I'm sure the same applies to the
> g_object_[dis]connect_valist functions too.  Every GObject API function that uses ellipses has a valist
> variant...except for the [dis]connect functions.  Not very consistent...or complete.

basically, _valist variants we introduce are just required to implement
necessary compatibility code, e.g. g_signal_new_valist() and
g_signal_emit_valist() are there to get the old gtk signal API going.
g_object_new_valist() is in place because many (not all) GObject derived
types provide convenience _new functions that also support property
lists.
g_object_{s|g}et_valist() usualy shouldn't be used since there's no
reason to wrap setting/getting properties, except for
1) gtk_widget_set() and friends compatibility functions
2) rare cases, such as gtk_list_store_set() where a property applies
   not to an object, but a pair such as (ListStore, TreeIter).

> 
> Eric.
> 

---
ciaoTJ