MObS (download) is yet another experimental object system. It's primary focus is to enable the programming styles of other modern languages in C++.
MObS is not yet useful for writing real programs.
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  = String ("foo"); // OK, a String is a Sequence seqs  = Array<int> (5); // OK, an Array is a Sequence // seqs  = Int (3); // COMPILE ERROR, an Int is not a Sequence // Run-time polymorphism assert (seqs.length () == 4); assert (seqs.length () == 3); assert (seqs.length () == 5);
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."Yet the C++ community rarely considers using C++ with garbage collection in mind, even though there clearly are usable implementations available:
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:
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).
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.