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

[Dave Benson <daveb idealab com>]

On Mon, May 16, 2005 at 10:10:17AM -0400, Matthias Clasen wrote:
> 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.
> 
> The principle is that you should be able to treat instances of derived
> types as if they were instances of the base type.

I guess i don't understand how
"List promises you to store arbitrary objects"..
How does memory management work?  How does the client
check the type of elements in the list?
It seems like you'd want a List<GValue> for that...

It seems like you *can* treat the derived class as the base class,
but the methods of the base class are quite constrained:
you can generically reverse a list, or compute its length.
But operations like "append" or "remove" doesn't really make sense
on the List generic class-- it must be a specific type of list
to do type checking.

- dave