There's an interesting book called Object Oriented Programming with ANSI C, which is on various websites as a PDF. As someone who didn't do computer science at undergraduate, it explained a lot about how other languages work - for example why Python passes self (well, self by convention) automatically to every method.
If you want to know how other languages could work, in the sense of an OO version of the lambda-cube, read Cardelli and Abadi's Theory of Objects: http://www.amazon.com/dp/0387947752
wow. this looks very interesting. the web site says that it's beta. does anyone have experience / anecdotes about how solid it is? seems like it would be very useful.
also, what approach does it take to memory management and / or deciding who owns what? i'm just glancing at the paper now (should really be working) and the lack of emphasis on that seems worrying - suspect i am missing something?
[edit: replying to myself, the key phrase is "ownership"; see section 2.1: Ownership The management of object life cycles requires a clear policy of ownership and scope rules. In languages like C and C ++ where semantic by value prevails, the burden is put on the programmer’s shoulders. In languages like JAVA, C # and D where semantic by reference prevails, the burden is put on the garbage collector. In this domain, COS lets the developer choose between garbage collection (e.g. Boehm GC [25]) and manual reference counting with rich semantic (section 3.5).]
How is this different or superior to languages like Objective-C and C++ ? Both provide C like syntax and have similar features as the system described here.
1) Objective C certainly does not provide generic functions and I doubt that Objective C++ does (C++'s static overloading is something completely different, although it might look similar).
2) And this is different exactly in that it is not a complete language, but a library of CPP macros and some supporting infrastructure.
CPP is "C PreProcessor", so your "C macros" are simply some subset of uses of "CPP macros". CPP can be (ab)used to preprocess other things than C source.
This compiles with a standard C compiler, so it's more appropriate to compare to something like GLib. Cos has faster single dispatch than Objective-C and has extensible multiple dispatch with significantly better performance than C++ (as implemented using Visitor, which is only extensible in one argument).
So ok, I just peeked at the paper and it seems great, but the disadvantage of being in C is that you end up with a lot of macros (like e.g. `defclass`): what with debugging?
This is a very good point and is the fatal flaw of most metaprogramming. It does seem easy to generate quite confusing error messages by making minor typos. Clang does a much better job with macro expansion errors than gcc, but it's still not great. As for actually using debuggers, it looks like you're on your own to understand the implementation enough to be useful. I don't know if it would be feasible to write a gdb plugin to improve the experience.
OTOH, Cos offers more compile-time type safety than GLib, so you might hope that you'd need to spend less time in the debugger.
The C preprocessor would emit #line <number> to preserver the original line numbers, this way the debugger won't get problems understanding it. This off course if the macro does not expand multiple-lines (if it does, you'll just skip all over that).
As a friend of mine likes to put it - "Objective-C is C raped by Smalltalk without proper understanding of the language anatomy". Not exactly accurate, but fairly close still :)
My first question about this thing is how "leaky" the abstraction is. If you frequently have to make allowances for how C is not _actually_ a language with an object system, that's going to be a problem. But it seems like it should be possible (with liberal macro use) to make a relatively leak-free abstraction, and if this is it, that's pretty cool.
http://ldeniau.web.cern.ch/ldeniau/cos.html http://sourceforge.net/projects/cos/