Beware Experts

I’m accustomed to making broad statements without qualification (hey, I was in Sales for a while). But the other day, I was reading the Web site of a somewhat popular Javascript library written by a PhD, and after nearly every article on the site, I had to shake my head and ask, “Is this what they’re teaching kids in Computer Science today?”

Just one of the things that made me shake my head: “The primary mechanism by which most modern OOP languages (such as Java and C#) implement this [Multiple Inheritance] is through the use of interfaces.”

Bzzzt! Wrong. And you’ve got a PhD? In What?

The danger of experts

Now I don’t really have a problem with some kid standing up on his virtual soap box and making a fool of himself before the ink is even dry on his precious PhD sheepskin. What I really have a problem with is the general calibre of developer using Javascript is such that this sort of mistake will be accepted as gospel.

How do I know? Well I didn’t stumble across this Web site out of thin air. I encountered it via links from several Web development sites and also coincidentally on del.icio.us. Those Web developers linking to this site were ecstatic that someone was mimicking the .Net library (questionable idea) and were terribly impressed with the doctor’s efforts.

What’s worse, is some of the code is quite good. I’d question the need for quite a lot of it, but that’s just because I’m very comfortable with Javascript and don’t need an extensive library like this.

I’m no expert

If you ever catch me claiming to be an expert at anything, call bullshit. I’ve written a lot of software over the years for numerous platforms with a variety of languages and libraries. That gives me perspective.

And I’m naturally opinionated. (Ask anyone who knows me well.)

Of course, I have a way of stating things that would enable you to think I’m an expert: I don’t go in for self doubt in the realm of software design. But I frequently change my mind when someone questions my ideas, because it’s just code.

Providing an alternative voice

I once worked for a guy who classified software developers into two groups: those that got it and those that didn’t. Of course, getting it was solely defined by him. But I like that description. Each of us finds somethings come naturally. For some of my colleagues, developing complex algorithms comes easily. For me, my brain overheats and melts down if I have to think up anything more complicated than a basic sort algorithm.

But I feel obliged to provide an alternative to “expert advice” which I consider plain wrong. Maybe I’ll succeed. Maybe I won’t.

But at least there’s a comment box on the bottom of each page where you can point out my (many) mistakes.

Comments

Simon August 27th, 2005 @ 5:42 am

What exactly is wrong about the statement about interfaces? I’d say they certainly play a large role in multiple-inheritance structures in Java.

Jeff Watkins August 27th, 2005 @ 8:18 am

Simon, Java and C# don’t support Multiple Inheritance at all. Instead they support single inheritance and interfaces.

Inheritance in the Object Oriented world is a form of code re-use. Take a quick glance at Inheritance (object oriented programming), Wikipedia. On the other hand, Interfaces are a promise to support the same behaviour. Also see Interface (computer science), Wikipedia, without the baggage of a particular implementation.

C++ supports Multiple Inheritance but doesn’t really support Interfaces. We mimic them using a class having only pure-virtual functions and no member variables. In contrast, Java and C# support Interfaces but don’t support Multiple Inheritance.

Objective-C supports Interfaces but not Multiple Inheritance, but it also supports the ability to dynamically extend any class using Categories. You can also completely replace method implementations using Categories. It’s very cool.

Javascript actually supports a limited form of Multiple Inheritance. Inside a constructor, if you call another constructor function the new object will inherit any properties and methods defined in that constructor. However, the new object will not inherit methods defined in the second constructor’s prototype chain. For example:

function FirstConstructor( name )
{
    this.name=name;
}
FirstConstructor.prototype.getName= function()
{
    return this.name;
}

function SecondConstructor( size )
{
    this.size=size;
    this.inflate= function()
        {
            this.size++;
        }
}
SecondConstructor.prototype.deflate= function()
{
    this.size--;
}

function TestMultipleInheritance( name, size )
{
    FirstConstructor.call( this, name );
    SecondConstructor.call( this, size );
}
TestMultipleInheritance.prototype= new FirstConstructor;

Any instances of TestMultipleInheritance will possess properties for name and size. In addition, each TestMultipleInheritance object will have a unique copy of the inflate method (because it was allocated in the constructor), and will inherit via the prototype chain the getName method of FirstConstructor.

You’ll only ever be able to tell that a TestMultipleInheritance object is also a FirstConstructor object using the instanceof operator. Without additional hackery, there’s no way to tell whether objects are also SecondConstructor objects. And in fact, TestMultipleInheritance objects aren’t entirely SecondConstructor objects because they are lacking the deflate method.

I know this is a contrived example, but I think it illustrates the point. I’ve never actually needed to use Multiple Inheritance in Javascript, and Javascript doesn’t support Interfaces.

Simon August 27th, 2005 @ 9:04 am

ah, ok now I understand your point - The author of the article shoudn’t have said “most modern languages (c#, java) implement this” since they don’t implement it. I immediately read ‘implement’ as ‘mimic’ I think.

The author would have been correct in saying that the way c# and java mimic multiple inheritance is by using interfaces (and delegation of course), wouldn’t he?

Thanks for the javascript example - I doubt I’ll ever need it but it’s always good to learn something. :-)

Jeff Watkins August 27th, 2005 @ 8:08 pm

I’m not certain you can actually mimic Multiple Inheritance, because the inheritance aspect is the key to the whole thing. With Interfaces you are promising to support the same methods (and something like the same behaviour), but you have to do all the work yourself.

With Multiple Inheritance there’s no need to promise, the object does support the same methods and you get the implementation for free.

I doubt if anyone has a really good reason to do even the slightly crippled Multiple Inheritance from my example. I know I’ve never needed it in almost a decade of writing Javascript.

Paul C January 10th, 2007 @ 12:47 pm

um.. you CAN mimic multiple inheritance in Java.

interface Cat {
void meow();
}

class CatImpl implements Cat {
public void meow(){}
}

interface Dog {
void bark();
}

class DogImpl implements Dog {
public void bark(){};

class DogCat extends CatImpl
implements Dog {
private Dog dog = new DogImpl();

public void meow() {
super.meow(); //I know this isn’t necessary..for clarity

public void bark(){
dog.bark();
}
}

In what way is this NOT multiple inheritance? And you can see with this example why MI can be a bad thing…Exactly what is a DogCat?