dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types

[Owen Taylor]

On Mon, 2005-05-16 at 15:16 +0200, Tim Janik wrote:
> On Fri, 13 May 2005, Matthias Clasen wrote:
> 
> > On Fri, 2005-05-13 at 13:01 -0400, Colin Walters wrote:
> 
> > As I just pointed out to Colin, using derivation to model the relation
> > between generic types and their specializations is not really adaequate,
> > since you violate the substitution principle: a List<int> can not be
> > substituted for a List, since List promises you to store arbitrary
> > objectds, while List<int> can only store ints (which is why generic
> > types systems like the one in Java 5 don't do it like this).
> 
> what kind of substitution is that? having an abstract or very generic
> base type (List) and specialization in derived types (List<int>) is
> fairly common practice in inheritance patterns.

On the instance level, it's pretty common that derivation of 
contained types doesn't give you derivation of containers. If you
have:

  class List<T> () {
      int length();
      void prepend(T t);
      T popFirst(void);
  }

Then List<Widget> doesn't derive from List<Object> because you
can't call prepend(object) on a List<Widget>.

Java 5 has the concept of List<?>. It's legal to call, for example,
length() on a List<?>, but you can't call prepend() on a List<?>.
(From memory, I might be getting details wrong.)

So, if we had a G_TYPE_LIST, it would be a List<?>, not a 
List<Object> ... the only operations on it would be the ones you
could perform on a list without knowing the type of the contained
objects.
 ... 
List<?> isn't really that interesting a type as described above,
but with GObject we add an interesting extra: we have classes as 
runtime first class objects. There are no interesting *instance methods*
that GTK_TYPE_STATE inherits from G_TYPE_ENUM, but there are 
interesting *class methods*. g_enum_get_value(), and so forth.

Similarly, while List<?> isn't that interesting, ListClass<?> is more
interesting, because we do have a useful method ... "give me 
the type of the elements in this list".

So, an extra layer of inheritance:

 G_TYPE_BOXED <-- G_TYPE_LIST <-- G_TYPE_LIST<GtkWidget>

May actually be modeling something useful. But that doesn't imply
that G_TYPE_LIST<GtkButton> should inherit from G_TYPE_LIST<GtkWidget>.

Is G_TYPE_LIST G_TYPE_ABSTRACT or G_TYPE_VALUE_ABSTRACT? You could
argue either way ... G_TYPE_VALUE_ABSTRACT says that there are *no*
interesting instance methods, but there are a couple for GList ...
length() and reverse() .... that make some sense.

I'd still argue for VALUE_ABSTRACT for the convenience of language
bindings. The language binding is going to either:

 A) Convert the GList to a native list
 B) Wrap and memory manage the GList

And you can't do either for a raw G_TYPE_LIST.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050516/55f61cee/attachment.pgp