Re: deprecation of gdk_drawable_xxx

[Havoc Pennington <hp redhat com>]

Oskar Liljeblad <osk hem passagen se> writes:
> 
> gdk_drawable_set_data
> gdk_drawable_get_data
>   - Not necessary (they call g_object_set_qdata_full/g_object_get_qdata).
>   - Two versions of gdk_drawable_set_data should be provided for
>     completeness: one with destroy notify and one without, just like
>     g_object_set_qdata{,_full}. Solution: Remove both.
> 
> gdk_drawable_ref
> gdk_drawable_unref
>   - Not necessary (they call g_object_{ref,unref}.
> 

Already deprecated, not removed in this release for compat reasons.

> I'm also curious why there are no
> 
>  g_object_set_data
>  g_object_set_data_full
>  g_object_get_data

These exist already. ;-)

>  g_object_remove_data
>  g_object_remove_qdata
>  g_object_steal_data
> 
> I think g_object_remove_data(obj, key) is slightly more readable
> than g_object_set_data(obj, key, NULL). Also, it may be tempting
> to use g_object_steal_qdata instead of g_object_set_data(.., NULL).
> The function g_object_remove_(q)data would overcome this problem.
> (As I understand it, steal_qdata should not be used because
> one is lazy, but because it is necessary to remove the data without
> notification.)
> 
> Another reason for adding g_object_remove_data is for the
> future possibility of allowing NULL data (like the Java
> Collections framework does)... Unfortunately this would require
> the behavior of g_object_set_data to be changed.
> 

We can't really allow NULL data without breaking a bunch of stuff.
remove_data() may be more intuitive - I think it sort of is, Owen says
he thinks it's kind of not, no one has strong feelings in the zone
surrounding my cubicle. ;-)

Havoc