Martin's Object System (MObS)

Introduction

MObS (download) is yet another experimental object system. It's primary focus is to enable the programming styles of other modern languages in C++.

Ideas:

• C++ libraries are designed with manual memory management in mind. Let's discard that assumption and enjoy automatic garbage collection.
• Pointers are evil. Can we enable pointer-less programming in C++? Our key idea for implementing this is to replace pointers with smart references.
• Let's use a modern object model.
• Automatic boxing of value types should be possible.
• Strongly separate implementation and interface.
• Don't give up on efficiency.
• Data types should be used to express concepts. What happens if we push that idea to the extreme?
• Enable mixing of static and dynamic polymorphism.

MObS is not yet useful for writing real programs.

Motivation

My inspiration was drawn from an unpublished experimental version of XEmacs based on C++ instead of C. Naturally, I discovered that I didn't understand either object systems or C++ deeply enough, so I digressed to do object system research.

One valuable way to approach language and library design is to try to map the programming paradigm of one programming language into the actual facilities available in another. C++ is particularly interesting because it has extremely powerful mechanisms intended to enable a plethora of programming styles, yet these mechanisms are poorly understood (even by their designers).

An example of the approach I'm thinking of is FC++, an attempt to enable efficient Haskell-style programming in C++.

I've been mining the following programming languages for object system ideas: Lisp, Java, and C#. Here's some of what I have now:

    // Lisp-like code ------------------------------------------------
    assert ("(1 2)"   == toString (cons (1, cons (2, nil))));
    assert ("(1 . 2)" == toString (cons (1, 2)));

    Object x = list (1, 3.4, "foo", true);
    assert (toString (x) == "(1 3.4 foo 1)");
    assert (car (cdr (x)) == 3.4);


    // Java-like code ------------------------------------------------
    Array<ISequence> seqs (4, String ("?"));
    seqs [0] = String ("foo"); // OK, a String is a Sequence
    seqs [1] = Array<int> (5); // OK, an Array is a Sequence
    // seqs [2] = Int (3);     // COMPILE ERROR, an Int is not a Sequence

    // Run-time polymorphism
    assert (seqs.length () == 4);
    assert (seqs[0].length () == 3);
    assert (seqs[0].length () == 5);

Garbage Collection in C++

Stroustrup has always advocated the use of garbage collection in C++. Just not by default. He has said,

"When (not if) automatic garbage collection becomes part of C++, it will be optional."

• Boehm's collector
• Great Circle
• Microsoft's .NET framework

We'd like to take Stroustrup's suggestion as an axiom and explore the consequences of using GC consistently with C++.

MObS uses Boehm's collector. A few comments about the collector:

• open source
• Users of Boehm's collector can adjust their effort to use the library from almost zero (simply add -lgc to the Makefile) to more sophisticated uses that require incrementally more effort.
• The collector includes an STL-compliant garbage collecting allocator. Although we don't like the STL API (too unsafe; we don't like value semantics for mutable objects), we can use the STL to implement our object system, and this allocator is useful there.

Why not just program in Java?

Programming in "raw" C++ is horrible in many ways. Why do it?

We can explore object system design alternatives.

For example, it's not obvious to me that allowing null as a valid value for every variable is a good idea. Perhaps a strongly typed static type system should distinguish between a guaranteed-to-be-initialized object reference and one that might be null.

It's also not clear whether automatic boxing is a good idea, nor what kinds of restrictions there should be on automatic boxing.

It's worth exploring using C++ as a target language for a compiler and generating high-level code.

We can enable multi-paradigm programming styles for current C/C++ programs (like XEmacs).

Ways in which Java will always be a better choice

My idea certainly has many practical negatives.

C++ will never be a safe language. A malicious user can evade all protections we try to provide. For example, it's possible to take the address of a class variable that has a private operator&.

The template techniques involved make compilation extremely slow. Use of advanced template techniques also causes portability problems. C++ compilers are notoriously unreliable. Because C++ compiler implementers have been trying so hard just to get the standard implemented, insufficient attention has been paid to producing highly optimized object code. It took five years after the publication of the C++97 standard before any vendor claimed to implement that standard. Yet there are so many holes in the standard that many are already waiting for the next revision, C++0x.

Although the library has the potential for efficient code generation, it is likely that compilers will be confused by the templates used to implement it (we certainly were writing them!).

My approach splits the world into library users, who enjoy the ease of use of Java, and library implementers, who carry an increased implementation burden. This will tend to dissuade ordinary programmers from creating new classes, contrary to the Java philosophy. (On the other hand, we believe that Java's object model dissuades programmers from creating new value classes — this is actually nicer in our system).

One of the reasons large companies use Java is precisely because the kind of object model experimentation we engage in is impossible. Java programmers deal with one consistent high quality object model. C++ programmers have to deal with a variety of object models, often implemented in an ad hoc manner. This accounts for part of the productivity superiority of Java over C++.

Much of programming design is finding the right tradeoff between flexibility and conceptual clarity. We don't have all the answers here yet.