Re: GTK's interfaces and language bindings

Il Tue, 18 Jul 2017 22:00:52 +0200 Stefan Salewski <mail ssalewski de> 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

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

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.


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