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