On Sun, 2005-08-21 at 14:05 +0100, Roger Leigh wrote: > > One thing I (as an end developer) would like is for libgobject to be > merged with libglib
That's off the table since it would break ABI ... > I currently find the split to make some tasks impossible (for example, > I recently wrote a GUnixSignalSource to inject UNIX signals into the > mainloop, but without it being a GObject, I couldn't implement it > completely). > You should have been able to link to libgobject and write it as a GObject though ? > Something else I would also like (but can implement separately > initially) is a GObject-based container library which implements > STL-style container and iterator interfaces. This would allow the > current list/hash/vector etc. types to be implemented as GObjects with > a standardised iterator interface, allowing the use of generic > algorithms etc. It would probably be hopelessly inefficient, since GObject is a bit heavier than a base object in Java or Python ... > Another thing I would be interested as an extension to the above is > specialisation (or rather, restriction) of containers to particular > GTypes. If for example, we had a call such as > > GType > g_type_specialise(GType type, ...) I think at some point you should accept you're coding in C ;-) if we just reimplement Java/C#/Python poorly, it's not that useful ... Havoc _______________________________________________ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list