Re: a new combo box

[Tristan Van Berkom <tristan upstairslabs com>]

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