Re: Alternative to swallow GtkContainer into GtkWidget

On Tue, Aug 02, 2016 at 04:48:03PM -0700, Jasper St. Pierre wrote:
What you miss is that GtkWidget already has container-like behaviors with
gtk_widget_set_parent. In fact, the whole API has been awkward. GtkWidgets
themselves can have children. GtkContainer is a "convention" interface for
a way of manipulating an object that can have children. Not every widget
that has children has to implement GtkContainer (though there *are* some
features that won't work automatically, like drawing of children, since
gtkwidget.c often has checks for GTK_IS_CONTAINER).

It makes sense to me to merge these two APIs so we don't have this
impedance mismatch.

You should at least be aware that GtkWidget violates several OOP
best-practices, namely [1] :

1. A class must know what it contains, but it should never know who
contains it.

2. Derived classes must have knowledge of their base class by
definition, but base classes should not know anything about their
derived classes.

3. Classes should not contain more objects than a developer can fit in
his or her short-term memory. A favorite value for this number is six.

Those OOP best-practices are not there just to bother developers,
following them makes a code easier to understand, more maintainable,

But I think you, the GTK+ maintainers, know what you're doing, of



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]