Classes / roles as sets / subsets

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?

Regards,
Richard

• Classes / roles as sets / subsets by Richard Hainsworth
• Fwd: Classes / roles as sets / subsets by Jonathan Lang
• Re: Fwd: Classes / roles as sets / subsets by chromatic
• Re: Classes / roles as sets / subsets by Daniel Hulme
• Re: Classes / roles as sets / subsets by Mark J. Reed