Originally this posting was written in response to the 'ref' spec thread. I included char diagrams that got screwed up, so I made a png diagram instead (attached) and I re-edited the posting to refer to attached diagram, and then added some more comments. Hope everyone can 'see' the png.

I find classes and roles, and multiple inheritance in general, difficult to understand. Larry Wall talked about subsets, so I have tried to analyse various situations using the idea of sets and subsets and Venn diagrams for demonstrating the relations between sets and subsets. The idea is that the 'space' encompassed by a set in the diagram (labelled as sets) is method functionality and attributes.

See diagram Case 1 (Class B is a subset of class A):

My understanding of inheritance in other languages is that Class A 'isa' Class B, and inherits all of the attributes and
functionality of Class B, and extends functionality and attributes.

It is also possible for Class B to be ('isa') Class A, and ignore the extra functionality of A, presumably to create objects that are smaller than the more general class.

My suggested interpretation of roles:
Class B is a role, and Class A is built from Class B, extending its functionality. A role without extra code becomes a class if it is instantiated.

See diagram case 2 (Class A and Class B intersect):

Usual OO technique:
Class B inherits the functionality of Class A, extends the functionality (in one 'direction') but then over-rides (anuls) some of the functionality of A (say, by redefining methods/attributes used in A).

Question: Is this the sort of behaviour that is forbidden in some languages.

Role-playing programming:
For the sake of programming sanity / ease of debugging, both Classes A & B are built from a role that represents their intersection ( Class A U Class B), and then code is added in the definitions of the classes to extend the functionality - possibly using over-riding with same-name methods/attributes for different types.

See diagram case 3 (multiple subsets):

This would require multiple inheritance.

In perl6 (I think), Class A would be built from the 'roles' of classes B-D.

But the question is what would 'ref' (or perl6 equivalent) return? Would it only define a match for (an object instantiated from) class A, or would it recognise the existence of Classes B-D in that same object? If so, how?

So suppose an object OA is an instance of class A and and object OB is an instance of class (role) B. Would object OA 'match' object OB in some form, after all the functionality of OB is contained within OA? But then, this matching might not be transitive, viz. OA ~~ OB might be true, but OB ~~ OA might be false because whilst OA contains the functionality of OB, OB does not contain the functionality of OA.

See diagram case 4 (multiple intersecting sets):

I dont know how other OO languages handle this.

But with roles, they could be used to reflect the intersections, and then the classes would be built from the roles.

Am I on the right track in understanding roles and multiple inheritance?


PNG image

Reply via email to