Web lists-archives.com

Re: GTK's interfaces and language bindings

Il Tue, 18 Jul 2017 22:00:52 +0200 Stefan Salewski <mail@xxxxxxxxxxxx> scrisse:

> ...
> So the second parameter is of type GtkStyleProvider, which is an
> interface. GtkCssProvider provides that interface, so we can pass a
> variable of that type. GTK_STYLE_PROVIDER() is basically only a cast, a
> re-interpretation of the bit pattern, maybe with additional security
> checks.

Hi Stefan,

I'll give you my view that will not necessarily match the view of
who wrote GInterface.

Although GTK_STYLE_PROVIDER() is similar to e.g. G_OBJECT(), they
are fundamentally different. While the latter matches exactly your
description (a GtkCssProvider is also a GObject), the former
should be considered only a check.

If you dig enough in that macro you will discover this function:


G_OBJECT() is matched by the first branch (support_inheritance)
while GTK_STYLE_PROVIDER() by the second one (support_interfaces).

This difference is purely theorethical though, because
GtkStyleProvider is not even defined. In other words one could
argue that GTK_STYLE_PROVIDER() is a real cast to an undefined

> ...
> So I assume,
> that for all functions which has interfaces as parameters, I can just
> pass all objects (gobjects) which provides that interface?


> I even guess hat interfaces are fully abstract entities, so we will
> never pass an instance of an interface, but always only objects
> providing the interface. So we have only to provide functions which can
> accepts all the objects providing the that interface, but we do not
> really need functions which would accepts the interface parameter type
> itself?

Correct. As pointed out before, even in C interface instances are
only dummy typedefs.

I see interfaces as a "contract" that (1) enforces an object
to implement some feature (properties and/or methods) and
consequently (2) gives the users a common API that can be used
across unrelated objects.

gtk-list mailing list