About XfconfChannel Object (Brian J. Tarricone)

[Brian J. Tarricone]

On Sat, 20 Sep 2008 23:07:11 +0200 ali abdallah wrote:

> > On Sat, 20 Sep 2008 13:42:12 +0200 ali abdallah wrote:
> >
> > > On Sat, Sep 20, 2008 at 12:32 PM, Brian Tarricone wrote:
> > > > ali abdallah wrote:
> > > > > Hi,
> > > > >
> > > > > Why the XfconfChannel and XfconfChannelClass are defined in
> > > > > the xfconf-channel.c, i'm asking this question since i
> > > > > couldn't derive an object
> > > > > from the XfconfChannel object!
> > > >
> > > > Er, why do you want to?  I assumed no one would.
> > > >
> > > > Not saying you don't have a valid use-case, but I'd rather not
> > > > go and change things without a reason.
> > > >
> > > I wanted to have an object wish is derived from XfconfChannel
> > > object and contains more data and functions to be used in my
> > > application, then i can call the *channel_get* and *channel_set*
> > > functions by casting the object to XfconfChannel type, just like
> > > a GtkWidget and GtkButton for example.
> >
> > So are you actually *extending* the XfconfChannel type?  I mean, are
> > you actually adding settings-related functionality to it, or are you
> > just using subclassing as a quick-and-dirty shortcut to avoid
> > having to carry around an extra pointer?
> >
> > If you're actually extending the object, I'd consider making the
> > class struct public, but otherwise you should just be using
> > g_object_set_data() to carry around a pointer to the XfconfChannel,
> > or stuffing it in a struct that has other data you're passing
> > around.
> >
> 
> Yes actually i'm extending the object and i want to add some
> functions to it, it's not really
> mandatory since the second solution that you are proposing is always
> valid, but well having to work
> with the GObject system for a long time now, i thought it is kind of
> standard the
> declaration of the GObjects.

What kind of functions do you want to add?  If you want to add normal
functions that operate on an XfconfChannel object, you don't need to
subclass it.  If you want to add *virtual* functions to
XfconfChannelClass (or rather, subclass it and add vfuncs), then yeah,
you need to subclass, but I can't think of a reason why you need to.

Really, I'm perfectly willing to make the XfconfChannel and
XfconfChannelClass structs public, and if you have a good use case,
please do let me know.  This is the perfect time to do it, before we
have a 'real' release of the library... if there's good reason.

	-brian

P.S.  Subclassing using GObject actually isn't done all that often
unless there's a decent benefit... In a language like C++, you'd
probably subclass a lot more often since it's trivial.  But with all
the work it takes to subclass a GObject in C, it's not done unless
there are clear benefits to doing so, in general.  (I remember when I
used to write Qt2 apps, it was common practice to always subclass
QWindow for your app's main window... but that's probably not so common
to do with GtkWindow in straight C, though admittedly I do it
sometimes.)