On Thursday July 09, 2009 5:32 PM Chris Robinson wrote:
With the same argument you could say that writing COM objects has to be done in C++. Yet Wine has lots and lots of COM code written all in standard C.
It has to, because the class vtable layout and calling convention can be different in Windows than how the host system's compiler will generate
it.
COM objects have to interface with existing Windows code, and so need to be setup in memory in a specific way.
Not entirely sure where your "It has too" is pointed at. If it is about COM code being written in C then it is not entirly true. All the MS examples about COM nowadays are completely in C++ and some newer API headers seem to not even include the C part. But of course that code is meant to be compiled with Visual C++ and I could see trouble trying to get the exact binary layout with gcc. This is maybe not such a problem with newest gcc but was certainly a problem with older versions.
If OSX will always have Obj-C support, and the Obj-C code can be restricted to OSX-only code, then the only sticking point, in my eyes, would be how maintainable it is. After all, if only one or two people can work with Obj-C code, it can bit-rot that much more quickly.
I think this is in fact the major issue here. There is certainly interest in starting such a project but maintaining it is a completely different beast.
Rolf Kalbermatter