>rset find exit 3301<
————————————————————————-
Room 3308 west -> Gravel path between hedges
Room 3349 east -> On a crunchy gravel path
52103 rooms searched.
2 rooms found with exits leading to room [ 3301] A branching of the path.
Links to/from zone [330] 'The Jo'Kerin Gardens'
—————————————————————–
Linkage out - room [ 3317] links to room [ 16605] at level 33 (diff 2)
Linkage out - room [ 3348] links to room [ 16698] at level 33 (diff 2)
Linkage in - room [ 16605] links to room [ 3317] at level 35 (diff 2)
Linkage in - room [ 16698] links to room [ 3348] at level 35 (diff 2)
Multiple inheritance says every object should be composed of code and data, and that the code should be factored into the simplest reasonable components.
If I make a spoon and a fork, those are two different tools. The spoon has a shallow bowl to hold liquids. The fork has sharp tines in a parallel row, to hold solids and also to stab them. Both tools have handles. In terms of their code, both the spoon and the fork have shared functionality. They can both hold things. They can both be lifted to transfer things from a plate or bowl to the wielders mouth. The spoon has a "dip" functionality, where it can be slid into a liquid to gather it. The fork has a "stab" functionality, where it can impale solids to gather them.
So, what would these tools inherit? Both would likely inherit the lift method and the hold method. You could put those in the same module and both could inherit it. Now, suppose you wanted them to both be made out of metal, and thus you wanted them to react the same to magnets, or to being heated? You'd want to code that functionality into another module that deals with those things, right? Because a wooden spoon and a metal fork wouldn't inherit the same material properties, but would inherit the same usage methods.
But, you WOULD want a metal spoon and a metal fork to inherit both the usage methods AND the metal properties, wouldn't you? That's multiple inheritance.
A lot of modern languages try very hard to pretend they don't do that, by making you only officially "inherit" a single parent, and then writing interfaces to "mix in" methods from other modules that would normally be inherited too, but can't be because it's all too common for people to not factor their modules very well, and thus end up with overlapping methods… and that's the only real issue with multiple inheritance. If you inherit several things that have "hold" methods, which one do you call?