Re: is glib too bloated?

[Peter Clifton <pcjc2 cam ac uk>]

On Mon, 2007-04-23 at 11:28 -0400, Tristan Van Berkom wrote:
> On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote:
> > On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote:
> > > It might be advantagous if alot of the glib data structures
> > > were moved somewhere above libgobject in the stack (glibutils ?),
> > > this way they could have the option of being gobject based,
> > > opening a whole new world of possible code paths and also allowing
> > > more generic access to these data structures through the gobject
> > > api (hash tables and linked lists could possibly be serialized
> > > by libglade and crammed through a network socket ? for an example
of
> > > a misc wild idea).
> > 
> > I think you mean "below" the gobject stack, don't you?  The data
> > structure libraries are required by gobject after all, aren't they?
> > 
> 
> Heh, yeah maybe my idea of gobject'ized glib data structs is a little
> futile :) not sure just exactly what I'd do with a derivable GList,
> I'm sure something random could come of it haha, maybe
> GQueues/GAsyncQueues could be extended glists etc - I guess in the end
> that sort of thing would just be libfancyobjects :)
> 
> Might be an interesting thing from a bindings point of view... I dunno

I've found myself wanting GObject derived GList. The idea is to have a
"list of things with some GType", and make the API which modifies that
list emit "changed", "deleted", "inserted" signals, etc. I coded a
GObject derived class to do most of this.

One thing missing with GList is type safety of course, but if you want,
you can add run-time type safety with a class around it.

Peter Clifton