On Sat, 2014-12-27 at 16:21 +0100, Sébastien Wilmet wrote: > On Sat, Dec 27, 2014 at 10:52:27PM +0900, Tristan Van Berkom wrote: > > From a quick look at gtkcombobox.h, the only really problematic part > > is the tabular menu nonsense (set_wrap_width(), set_row_span_column(), > > set_column_span_column()). Is there any way we could get around that ? > > perhaps just an additional GtkComboBox subclass which explicitly does > > not support those tabular menu things and thus would not be an API > > break ? > > Overriding a function with a NOP is generally not a good idea, it breaks > the logic of inheritance. A derived type should be a specialization of > its base class. The derived type *is* also (a kind of) the base class. > If the base class supports operations A and B but a derived class > doesn't, then the derived class is *not* a kind of the base class, > logically. The inheritance hierarchy should be reversed in that case, so > that only the derived class supports operations A and B. Or create a > common base class or interface with two subclasses.
Sure, it was suggested as a practical 'cheat' to get away with not implementing some of the more odd-ball features from combobox which I have doubts that anyone is actually using. The reverse approach would IMO be worse, since any additional features which the new beast might bring to the table would be expected functionality in the older combo, while explicitly implementing some vfuncs with g_warnings() on a few APIs, possibly deprecating those tabular menu APIs in the parent GtkComboBox API), is not really a bad side effect. In any case, I think this misses the point I was trying to make, I think someone had to raise the obvious question: is it justified to bring in a whole new combo API ? Or can we / should we get the most out of the API we have ? Cheers, -Tristan _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list