On Sun, 2005-04-24 at 11:15 +0100, Roger Leigh wrote: > Looking at GSource itself, it looks like it would be cleaner and > easier to use if it was a GObject I'd agree there. In retrospect I consider the separation of libglib from libgobject a mistake ... it would be better if a number of objects in GLib (the main loop, IO channels) were done as gobjects. But it's not really possible to change and do things that way at this point. > , and the same applies to quite a > number of glib types, including the container types. If the list > types, for example, were GObjects, some operations would become rather > more efficient if the object was a list head, which would then allow > for caching, and not returning the first GList node for every > operation changing the list saves needlessly traversing the list when > e.g. appending. It might also be possible to restrict the list > contents to a particular GType, set callbacks for automatic sorting, > freeing nodes etc., and store GValues rather than gpointers in the > nodes. This would also provide the opportunity to add common > container interfaces e.g. GIterator, GContainer for all container > types (which could also be implemented by e.g. GtkContainer). If you look at the cost of creating a GObject, it would be prohibitive to use them for something like GList. At some point, C is C, and there is only so far you can or want to go there. I think trying to make container types too high-level is generally not a good idea. > Are any changes like this planned for glib 3.x? We're not planning a glib-3.x in the forseeable future... the cost of a new major version of GLib are huge (every single library that depends on GLib needs a new major version). Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part