Re: type system deprecation

[Tim Janik <timj gtk org>]

On 31 Jan 2001, Havoc Pennington wrote:

> Hi,
> 
> Realized I left the type system out of my previous post. Appended is
> the list of possibly-deprecated type system
> symbols. Additions/corrections welcome.

i have some comments:

> 
> Havoc
> 

>  GTK_STRUCT_OFFSET
this one should simply be nuked right away.

>  GtkArgGetFunc
>  GtkArgSetFunc
nuke these right away, been deprecated since pre-1.2

>  gtk_arg_copy
>  gtk_arg_free
>  gtk_arg_get_info
>  gtk_arg_info_equal
>  gtk_arg_info_hash
>  gtk_arg_name_strip_type
>  gtk_arg_new
>  gtk_arg_reset
>  gtk_arg_to_valueloc
>  gtk_arg_type_new_static
>  gtk_arg_values_equal
>  gtk_args_collect
>  gtk_args_collect_cleanup
>  gtk_args_query
leave these alone, i'll take care of nuking them once
i settled code on container args.

>  gtk_object_arg_get_info
>  gtk_object_arg_get
>  gtk_object_arg_set
>  gtk_object_args_collect
eh? there are no gtk_object_arg.* functions anymore.

>  gtk_object_class_user_signal_new
>  gtk_object_class_user_signal_newv
we don't have this in CVS anymore.

>  gtk_object_data_force_id
>  gtk_object_data_try_key
nuke these, been deprecated long enough.

>  gtk_object_getv
>  gtk_object_newv
>  gtk_object_query_args
>  gtk_object_setv
no such functions.

>  gtk_signal_add_emission_hook
>  gtk_signal_remove_emission_hook
i'll nuke these in time anyway.

>  gtk_signal_connect
>  gtk_signal_connect_after
>  gtk_signal_connect_full
>  gtk_signal_connect_object
>  gtk_signal_connect_object_after
>  gtk_signal_connect_object_while_alive
>  gtk_signal_connect_while_alive
maybe we should have the guts to nuke _while_alive right away.

>  gtk_signal_init
definitely needs to be nuked (people need to figure
that they want g_type_init() right away if at all).

>  gtk_type_enum_find_value
>  gtk_type_enum_get_values
>  gtk_type_flags_find_value
>  gtk_type_flags_get_values
i think these are good candidates for plain removal also.

three things on the functions i marked for removal above:
1) they are considered currently rarely used, thus breaking their
   source compatibility doesn't hurt too much
2) for most of them, mechanisms have significantly changed, so,
   that it's worthwhile to notify programmers via source
   incompatibilities of code portions they should pay attention to
3) all of them have to be sufficiently marked in Changes-2.0

---
ciaoTJ