Re: g_object_class_install_property, but no g_object_class_remove_property

[Tristan Van Berkom <tristan van berkom gmail com>]

On Thu, 3 Mar 2005 14:54:52 +0100 (CET), Tim Janik <timj gtk org> wrote:
> On Wed, 2 Mar 2005, Stefan Kost wrote:
> 
> > hi,
> >
> > is there a logical reson against having g_object_class_remove_property() as
> > well.
> > I looked at the code. g_object_class_install_property() uses
> > g_param_spec_pool_insert() and there is a matching
> > g_param_spec_pool_remove(), so should be fairly easy to be done.
> >
> > My scenario. For GStreamer I would like to do musical instrument plugins. An
> > instrument can have multiple voices.
> > Properties are e.g.
> >
> > properties common to all voices:
> > waveform, filter-type, ...
> > properties per voice
> > note_%02d, volume_%02d, ...
> >
> > Means, I would like to add the same set of properties a multiple times (thus
> > the number post fix).
> > While I can do that, I cant easily get rid of them. I would like to avoid
> > calling
> > g_param_spec_pool_remove() myself.
> 

Hmm, 
    strangely I fell upon the same konundrum, I was implementing an observer
model using GObject (since properties and change::notification was just what
I needed); basicly its a singleton GObject that offers an API like this:

void            gtktt_statepool_add_string (GtkTtStatepool *pool,
                                            const gchar    *name,
                                            const gchar    *string);

(and add_object, add_int and so on and so forth).

Then the calling code sets & gets the value with g_object_set()/get()
and connects to the "notify::name" signals and voila!

In the context in which I need to use this observer object this doesn't pose
a problem (because I dont need to remove any of the observed subjects),
but I have to admit that I would have written gtktt_statepool_remove_subject()
if possible just to offer a complete API.

> you can't call g_param_spec_pool_remove() yourself because the pool handle used
> for class pspecs is not exposed by GObject and deliberately so.
> class pspec removal logic is not in place by design, GObject and code based on
> it should not have to deal with the complexity involved in having pspecs be
> removed during a class' or object's life time.

Including g_object_class_uninstall_property() does not impose the GObject
writer to use this API or to add complexity to thier code, it just
allows for the
possibility of someone using the GObject framework for yet another totally
unexpected purpose, should that be considered a "really bad thing" ?

Stefan, 
    maybe I'm off track but is it saner OO coding to say that you should have a
GStreamerInstrumentClass with the properties: waveform, filter-type etc.
and then derive your GStreamerGuitarClass & GStreamerTrumpetClass to
add more specific properties ?

Cheers,
                                                               -Tristan