Re: ABI and API for g_object_ref_sink() (Re: GTK_FLOATI

[Tim Janik <timj imendio com>]

On Thu, 15 Dec 2005, muppet wrote:

> On Dec 15, 2005, at 7:07 PM, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
>
> > 2) If it was decided to wait until 3.0, can GtkObject be removed entirely? 
> > (Or
> > can we work to eliminate GtkObject if there are any other remaining
> > functionality?)
>
> GtkObject adds various things to GObject:
>
> 1. a flags field

this would be wrapped by accessors anyway.

> 2. the floating reference (stored in the flags field, incidentally)

is on its way into GObject already.

> 3. the destroy signal

will never end up in GObject.

> 4. a user-data property (this one is far surpassed by GObject's arbitrary 
> data keys, but is there to ease porting from 1.x)

this is long deprecated anyway.

> 5. the compat layer for GtkArgs (which were replaced by GObject properties, 
> but that's not so important and will probably be removed entirely in 3.x)

this is also long deprecated.

> I have heard it said on this list before that GObject is meant to be small 
> and every attempt will be made to keep it small, so adding a flags field is 
> likely not going to happen.

it won't happen, GObject will never gain new fields (that might make it
inapropriate for contexts it's currently used in). you'll have to
subclass instead.

>  It can't happen in 2.x because that would change 
> the size of the GObject instance and break ABI.
>
> The destroy signal is actually very useful, and i'd like to have one in 
> GObject.

this would be a real semantic change for GObjectand tehrefore won't happen.
whether an object implementor wants to allow destruction, and if he wants
to support multiple desttoy invocations (GtkObject/GtkWidget does that) or
not are dcisions that can't or shouldn't be made by GObject.

>  From a language binding it's not very easy to hook into GObject 
> destruction without subclassing, but GtkObject's destroy makes this easy.

there is no such thing as a GObject destruction. a GObject can just be
disposed (means: break any references it may hold to other objects), and
that multiple times, and at some point it will be finalized.
a language binding already can hook up weak references to do stuff upon
dispose, and other kind of user data it sets up will be removed with finalize.
additionally 2.8 introduced toggle references specifically for language
bindings, so there's really nothing left from a binding perspective to hook
into a GObjects lifetime.

> However, adding this would change the size of the GObjectClass structure and 
> therefore cannot happen in 2.x.

there's padding in that class, this would not be a problem, but it
still won't happen.

---
ciaoTJ