RE: ::scr usability, languages and apis

["Simon Kinahan" <simon@xxxxxxxxxxxxxxxxxxx>]

> This, I think is exactly the case. I'm in two minds about
> multiple inheritance
> - sometimes I think that if you need to have multiple inheritance
> then often
> you've designed your APIs wrong ... other times I think it's the greatest
> thing since sliced bread :
>
> A horse should extend mammal and moveable
> A car should extend manmade and moveable
> A hosue should extend manmade and immoveable

It usually seems to be true that cases where you want to use multiple
inheritance can be handled using single inheritance plus interfaces, as Java
provides (or single implementation inheritance and multiple interface
inheritance, as it might better be called). Your examples above are good
examples of this: the second class for each thing ends in "-able", which is
a sure sign of an interface.

It seems a lot of thinking about inheritance is actually quite confused,
because there are several things going on: on the one hand saying A extends
B, is saying "the set of all As is a subset of the set of all Bs", on
another its saying "given an A, everything that is true for all Bs will be
true for it", on another, its saying "A is implemented in the same way as
B". People (and languages) muddle these ideas up a lot.

The middle meaning is maybe the most important one. The first seems too
weak: it could even be understood as changing the meaning of B (and indeed,
sometimes people use inheritance this way). The last seems too strong: I
usually don't care about the implementations of A or B, just about what
they'll do for me, but its the one that OO language designers emphasise.
Interface inheritance seems to express that middle idea partially, though
not completely.

While there is definitly more than one way to divide the world into sets of
things, multiple inheritance of implementation seems wrong to me in most
cases, though "mixins" such as the ability to be treated as part of a linked
list, are a possible exception. In essence, a class is meant to be a highly
cohesive cluster of methods and data, where almost every methods depends on
almost every bit of data. Using multiple implementation inheritance implies
a class is doing at least 2 different kinds of things.

> I've never really found a good explanation of Aspect Orientated
> Programming.

Me neither, but it seems the idea is that you can tell the system to to
things before methods are called, or when particular items of data are
modified, or refine the type specification for fields, outside of the class
definition itself. The idea seems to be to further separate implementation
concerns from defining overall behaviour.

Simon