Next let us make the idea Female reusable. As order is irrelevant for set intersection, we start by swapping Human and Female:
as Female {
as Human {
def buy_more_shoes() { ... }
def give_birth() { ... }
}
}
We can now express something that we could not express earlier: the fact that give_birth() applies to many kinds of females, while walking on high heels is a skill specific to human females:
as Female {
def give_birth() { ... }
as Human {
def walk_on_high_heels() { ... }
}
}
As might be expected, a more specialized method give_birth() for human females could be added in the intersection. It might then involve playing Tetris (although this seems highly unlikely).
If we would create an object of a class that consists only of the idea Female, it would provide the basic method give_birth(), and no walk_on_high_heels() at all.
If we would create an object of the class Woman, on the other hand, all the most specialized methods would be available. Methods in the intersection of Female and Human would be preferred over methods with the same name in the separate ideas. For a Woman named mary, mary.play_tetris() would refer to a method in the intersection if a method of that name was available there; if not, it would refer to a method in either Human or Female.
As there is no hierarchic relationship between Human and Female, when both the ideas Human and Female would happen to define a method with the same name, and the intersection did not resolve the conflict, neither version of the method would win out, and it would be an error to send a message of that name to the object.
More generally, for a class that combines several ideas in which a same method name occurs several times, the top method, as we will call it, is the method of that name in the smallest intersection that encompasses all the ideas and intersections of ideas that define that method, if such a method exists at that place. If not, there is no top method. ("More specialized than" is not a total order.)
Now let us reuse the idea Female in the animal kingdom:
as Bovine {
def look_at_passing_trains() { ... }
}
class Cow = Female Bovine.
For a Cow, only the part of Female outside of the intersection with Human is relevant: the intersection with Human is simply ignored in composing this new class. The intersection of Bovine and Female on the other hand is still empty, so let us now add a method moo():
as Bovine {
def look_at_passing_trains() { ... }
as Female {
def moo() { ... }
}
}
The method moo() characterizes Bovine rather than Female -- I personally associate the concept of mooing with bovines rather than with femininity -- and that is why I add moo() to the definition of Bovine, further nested in Female, rather than the other way around. I opened a new block for the idea Female in this example, away from its original definition: ideas can be reopened as often as needed, as an outer nesting as well as nested in others. I could also have used a new Bovine-block, but instead chose to add to the one from the previous example. The two methods that are now inside the same Bovine-block seem to go well together thematically.
When one arranges methods thematically by reopening ideas several times, tools can be provided to view the code by complete ideas, or complete classes, or to see all variables in a certain scope together, to help understanding. Such a tool, called the Idea Browser, is still in the vaporware stage, but it is not intrinsically hard to make one. Tools for the opposite direction, that could rearrange code of traditional classes by theme or concern, would be harder to produce.