Re: Deprecating gtk_signal_* gtk_object_*

[Tim Janik <timj gtk org>]

On 20 Oct 2001, Owen Taylor wrote:

> 
> Based on comments in the documentation, #61942 calls for
> for marking virtually all of gtkobject.h GTK_DISABLE_DEPRECATED.
> (Except for gtk_object_sink(, gtk_object_destroy())

i assume you mean ::destroy, as gtk_object_destroy() is easily
deprecated by gtk_widget_destroy.

> If we do that, we should presumably correspondingly deprecate
> all of gtksignal.h.
> 
>  - Pro: People would be better off not using this stuff in
>    new code, and deprecating it hopefully will hopefully
>    provide protection against people using it in example
>    code.
> 
>  - Con: Making code GTK_DISABLE_DEPRECATED clean becomes
>    even more of a pain and people may just not bother.
> 
> In balance, I think I favor doing this, but I'd like
> other opinions.

i think the outcome will be somewhat odd. you're not supposed
to use GtkObject e.g. to ref widgets or set data on them, otoh,
you have to use it for sinking, and ::destroy and need extra
casting for that.
imho, if we decide to deprecate GtkObject and put the burden on
third-party authors, then we also need to walk the full path, i.e.:

- deprecate all of gtk_object_* and ::destroy
- provide gtk_widget_sink()
- deprecate gtk_widget_destroy()
- provide gtk_widget_break_refs() and ::break-refs
- emit GtkObject::destroy from GtkWidget::break-refs for
  backward compat

so, as a result, the broken ::destroy conotations are
gone except for compat, and people don't need to worry
about GtkObject in any code.
of course, compat emitting ::destroy from ::break-refs is
another performance hit to take.

> 
> Thanks,
>                                         Owen

---
ciaoTJ