Re: dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types

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

  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
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:


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

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.


Attachment: signature.asc
Description: This is a digitally signed message part

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