GObject property virtualization

[Dave Benson <daveb idealab com>]

I had some random comments about gobject's property mechanism,
i'm not sure it's really worth pursuing, since i've got
well-working workarounds in place, but food for thought...

For language-bindings, and similar purposes, it
is often beneficial to bypass the gobject property
mechanism:

  - it is a bit of a pain to implement a property-id
    allocation system, and then implement get_property()/set_property()
    appropriately.  the problem grows worse if subclassing
    is considered.

    for other projects i've added a new property system with:
       my_object_class_add_property_full (MyObjectClass *class,
                                          GParamSpec    *pspec,
					  MyGetFunc      get_func,
					  MySetFunc      set_func,
					  gpointer       data,
					  MyDestroyNotify destroy_instance,
					  GDestroyNotify destroy);
    the destroy_instance function is called from finalize, and 
    provides e.g. string parameter the opportunity to free themselves.

    One can add additional macro gobbledegook to
    make a nice macro that adds an integer property to the class,
    using only the name of the object-type and the member-name.
    (It uses offsetof to figure out where the member to set is located)
    Same for essentially any other property type,
    though there are perhaps caveats.
    Many objects have to do special things when a property changes,
    and so such simple macro properties are useless;
    but other objects are factory-type objects, and simply need a member set.

    So, in one project i have:
      UF_OBJECT_CLASS_STRING_PROPERTY (object_class,
                                       MyObject, string_member_name,
				       "string-member", "String Member", "The String Member",
				       NULL, G_PARAM_READWRITE);
    and that takes care of the get_property(), set_property() and finalize().
    It uses an inline function and hackery to ensure that string_member_name is a 'char*'
    (or at least warn if it isn't).

    it seems like it would be easy to graft this into gobject,
    i could provide patches pretty easily.

  - it would be nice if g_object_new() could fail... i really think
    that a system that supported property-setting to fail would be useful.

    in my systems, at least "MySetFunc" returns a gboolean
    with GError-style handling.   But that may not be deemed acceptable
    for gobject.

in any event, on the plus side, gobject has been totally flexible
enough for my needs to introduce these things in a subclass,
so that works nicely...

just some random thoughts,
dave