On Fri, 8 Dec 2006, Tristan Van Berkom wrote: > On Fri, 2006-12-08 at 17:49 +0100, Tim Janik wrote: > [...] >>> This abstraction would ensure that there is no confusion at the GType >>> level, if we start substituting types at the GType level then types >>> will inevidably be substituted underneath unsuspecting code, that >>> doesnt sound safe to me at all, >> >> we will not do that. never ever. i've adressed that in another >> email already: >> http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00133.html >> i.e. we guarantee that: >> G_TYPE_FROM_INSTANCE (g_object_new (TYPE_FOO, NULL)) == TYPE_FOO. >> holds, you may assert that in your code. we will not break that guarantee. >> >> let me use your words: we will not substitute types at the GType level. > > I see, thank you very much for your patience in describing this, > for my concerns: > a.) G_TYPE_FROM_INSTANCE(g_object_new(TYPE_FOO)/foo_new()) == TYPE_FOO
these are actually two cases, g_object_new and foo_new. if you read my original proposal again: http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00125.html you will see that i was suggesting that we change all gtk_*_new() functions (note, this affects only GTK functions) to return instances *conforming* to the requested widget types. that's what the pluggable widget types for Gtk+ is all about. so for the GTK namespace, only these will hold: G_TYPE_FROM_INSTANCE (g_object_new (GTK_TYPE_FOO, NULL)) == GTK_TYPE_FOO GTK_IS_FOO (gtk_foo_new()) > b.) IS_FOO (g_factory_create (TYPE_FOO)) this should hold. yes. so for Gtk+, the idea is to change internals like this: GtkFoo* gtk_foo_new (void) { - return g_object_new (GTK_TYPE_FOO, NULL); + return g_factory_create (GTK_TYPE_FOO, NULL); } > Knowing that the above assertions hold, completely settles my concern. hope your concerns are at least 66.6% settled now ;) > > Cheers, > -Tristan > > --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list