On Fri, Dec 7, 2012 at 4:06 PM, Zeeshan Ali (Khattak) <zeeshanak@xxxxxxxxx> wrote: > On Fri, Dec 7, 2012 at 11:34 AM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: >> Hi, >> >> libosinfo has various *List classes which basically are a GObject class >> wrapping a hash table of objects of a specific type. Each of these classes >> implements osinfo_list_new_filtered, osinfo_list_new_copy, ... probably >> because of c&p. I don't think that is the case. The issue is that these functions should have been virtual so if you call osinfo_list_new_*() on an instance of subclass, you get an instance of subclass (although in the form of OsinfoList). Now with these method deprecated in subclasses, apps now have to deal with different classes depending on whether or not they needed to call any of these methods (e.g whether or not they needed to filter a list). This Boxes patch should give you an idea of the issue I'm talking about: http://bugzilla-attachments.gnome.org/attachment.cgi?id=231171 Now the problem is that we can't make these methods virtual without breaking the ABI. Which is where another of our failures show-up. To avoid ABI breakage, its really important to keep redudant padding in class structs and we never added those before declaring libosinfo ABI stable. :( On a personal note, I don't think its a good idea for any API should be declared stable forever before it going through at least a few unstable and stable cycles. > However, these methods are seldomly used, and are not used >> at all on most classes. >> It's actually possible to implement these generically in the OsinfoList base >> class, this is what this series is doing while deprecating all the other >> implementations in derived classes. >> I've checked that make check is still working and also ran a quick test >> with Boxes. > > Series looks good. Since you have also tested it, ACK! I did a very bad job on reviewing these and totally missed the main point. Rest assured I wont' be able to sleep tonight. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list