Re: Pluggable widget types and implementations

[Paul Pogonyshev <pogonyshev gmx net>]

[ This mail may not land in the thread since I was not subscribed to
  the list when it began. ]

Tim Janik approach seems not general enough to me.  I.e. if GTK+
developers don't provide *_appoint_type() function for a particular
type, you are lost.  Are there any strong points for this version?
Let me propose another one for comparison.

Functions:

* g_object_factory_appoint_type (GType basic_type, GType appointed_type)

  Requires that `appointed_type' is a subclass of `basic_type', much like
  in original proposal.  The difference is that all *_appoint_type()
  functions are replaced with a generic mechanism.

* g_object_factory_new (GType type, <arguments like for g_object_new()>)

  Creates an object of type appointed to `type'.  If no type has been
  appointed, works exactly like g_object_new().

There may be additional functions for e.g. querying appointed type, but
they are not necessary for implementation.  May be handy for things like
Glade, though.

Changes:

* Constructors of all objects and widgets use g_object_factory_new()
  instead of g_object_new().

If no type appoints have been made, there will be absolutely no changes
in the way GTK+ applications behave.  If someone appoints a customized
type, it is her responsibility to make sure it doesn't break standard
conducts (minimal requirement for this is enforced by
g_object_factory_appoint_type().)

Advantages over initial proposal:

* More generic, requires less changes in the existing code.

* No need to write lots of *_appoint_type() functions, you are done
  with a single function.  Therefore less clutter in the docs.

Disadvantages:

* Marginally slower (if we assume best possible implementations of both
  proposals.)

* A tiny little bit less clear interface.  (Arguably, even.)

Paul