On Tue, 28 Nov 2006, Murray Cumming wrote: > On Tue, 2006-11-28 at 15:03 +0000, Ross Burton wrote: >> On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote: >>> Resulting in gtk_file_selection_new() to return objects of the custom type >>> gtkfileselector_derived_type, and gtk_printer_selection_new() to return >>> objects of the custom type iface_implementation_type. >> >> How would this interact with libglade/GtkBuilder, where dialogs are >> created at runtime? I'm guessing that GtkBuilder uses g_object_new() to >> construct the objects. > > This would also be an issue for language bindings. By convention, the > _new() functions are considered as mere C convenience functions, and > many language bindings (and some C applications) just use g_object_new() > directly.
i guess that depends on whether the language binding means to provide a function LB_create_exactly_type_foo(), which would remain to be a call to g_object_new (TYPE_FOO, NULL); or whether it wants to provide LB_create_compatible_with_type_foo(), which would be gtk_foo_new(). > If you want to replace implementations of GTypes, I think it would be > simplest to change the associations inside the GType system. this would break perfectly valid assumptions like: G_TYPE_FROM_INSTANCE (g_object_new (TYPE_FOO, NULL)) == TYPE_FOO. same for classes, etc. if at all, this would have to be a new libgobject function, like (brainstorming some here): g_factory_create (TYPE_FOO, NULL); // returns TYPE_FOO object g_factory_appoint_type (TYPE_FOO, TYPE_BAR); // TYPE_BAR is_a TYPE_FOO g_factory_create (TYPE_FOO, NULL); // now returns TYPE_BAR object > -- > Murray Cumming --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list