Re: Private types inside GTK+

[Tristan Van Berkom <tristanvb openismus com>]

On Thu, 2010-09-09 at 10:18 -0400, Matthias Clasen wrote:
> On Thu, Sep 9, 2010 at 5:28 AM, Tristan Van Berkom
> <tristanvb openismus com> wrote:
> 
> No comment on your larger refactoring ideas.
> 

Right, the point was more about letting us write more
modular code inside of GTK+ without introducing unnecessary
api ... and also allow us to drastically change the way 
things are done internally without breaking any public apis.

> >
> > Are there any technical limitations that dont allow us to create
> > widget/object types that are completely internal to GTK+ ?
> 
> GObject has no notion of private types. All types in the hierarchy are
> exposed. You can leave types undocumented, and keep constructors to
> yourself, but people can always call
> 
> g_object_new (g_type_from_name ("bla")...)

That's a point.

Well, are we comfortable writing code in this way and telling
people that if it's not in the headers and not in the docs,
it's not a backwards/forwards compatible type and people are
simply not supposed to use it ?

Or... is it worth the effort of writing an api for
gobject along the lines of:

GObject *g_private_object_new (GType type, gulong key, ...);

The type itself could be declared with a "private" flag
and a private object would not be instantiatable with g_object_new(),
g_object_private_new() would error out when fed an invalid key..
and the key could be generated at build time to ensure that
any offending client libraries/applications break any time they
update to a new GTK+ build... kindof intense I guess but would
pretty effectively disable any unauthorized use of private types.


At this point I'm not entirely sure that writing such a patch
for gobject will be worth the effort simply for the sake of
refactoring GtkComboBox... maybe it's worth it and maybe not.

However I'm still interested to know whether we are generally
interested in privatizing internal delegate types in the interest
of breaking things down internally and writing more OO/modular
code under-the-hood for GTK+.

Interesting for GTK+ or not ?

Cheers,
           -Tristan