Design implications of MI strategies

While doing research for my OSCON talk on roles, I was struck by something very interesting. You could, if you wish, group OO languages into multiple inheritance and single inheritance camps. Languages like C++ and Perl, which allow multiple inheritance, generally have taboos against it. As a result, experienced developers create designs which allow them to avoid multiple inheritance.

Single-inheritance languages, such as Ruby and Java, tend to offer language features to substitute for the lack of MI (e.g., mixins and interfaces). For these languages, use of these features is encouraged and hyped, as opposed to MI being discouraged and avoided. I'd be rather curious to know how this impacts the software design trends in those languages.

1 Comment

I'm not sure if it's entirely relevant but I noticed while reading the MRI Ruby VMs (1.8 and 1.9) that possibly Ruby's OO implementation might be completely replaceable.

It's somewhat plausible that for various optimization (whether premature or not) C functions will have short-cut doing some proper method calls to resolve things. This may prevent some existing C functions in the MRI vms from being cleanly reuseable. I noticed this in particular while reading the Hash implementation. Instead of merely calling the .hash method to get a FixNum on all its keys, it did:

  hash =
    if key.is_a( String ) then
      private_thing_for_strings( key )
    elsif key.is_a( FixNum ) then
      private_thing_for_fixnums( key )

The problem with the above is that it makes it impossible to subclass some of the core datatypes and expect it to respect a possibly replaced .hash function.

Anyway, it's entirely possible to change how Ruby works at a very deep level except for the parts that are semi-randomly hardwired.

Leave a comment

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book!