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
Attachment:
signature.asc
Description: This is a digitally signed message part