Adriaan van Os wrote:
Objective Modula-2 wrote:
J. David Bryan wrote:
I'm still not clear on Adriaan's original point, though. Does GPC currently support Objective-C message passing syntax,
No, but we now talking about the future of GPC.
I wouldn't say it is crucial in the sense that it is a requirement to support interfacing to Objective-C. However, if the target language you translate to supports Objective-C interfacing already and does so well, then you can save yourself the effort translating all the way down to the low-level C API of the Objective-C runtime. You can translate to the (hopefully) higher level statements of the target language and let the target language's compiler do the heavy work for you.
Yes, it is not a requirement, but it does make things easier to implement. And with more and more system (and other) software (for all kinds of platforms) written in C+ and Objective-C it becomes more and more important to be able to interface with C++ and Objective-C.
As for C++, that's exactly my original proposal. :-)
As for Objective-C, I'm not very familiar with it. Do you have a list of features that would need to be added to support these libraries? (I.e., not necessarily 1:1 compatibility, but the major obstacles that can't be easily worked around -- for comparison, in C++ this would be templates, automatic con-/destructors and exceptions, in this order.) -> see below
Objective Modula-2 wrote:
J. David Bryan wrote:
I'm still not clear on Adriaan's original point, though. Does GPC currently support Objective-C message passing syntax,
I don't think it does.
No, it doesn't.
For example, when using Objective-C style message passing syntax in Objective Modula-2 ...
VAR foo : NSArray := [[NSArray alloc] init] ;
for the ObjC target, the above only needs to be translated to
NSArray *foo = [[NSArray alloc] init ;
which is very straight forward. However, for an C target, there is a whole lot more to be done to translate just this one line.
C is, of course, as often, a bad comparison. In C++, given a suitable (one-time written) runtime support, it would become quite a bit easier.
After reading a bit about Objective-C, ISTM some of the major differences to C++ are:
- Classes are also objects (so you can, e.g., pass a class to a function that uses this class to allocate any number of objects of this class). While the C++ object model doesn't support this, it can be emulated with templates, almost completely automatically, as long as the set of operations on a general class object is known (which I suppose it is -- in the examples I saw, it was mostly instantiation, but there may be a few more).
- All classes have a common ancestor. (That's not a new thing, we've had this discussion WRT Pascal object models.) Many Objective-C proponents seem to tout this as a big advantage, I see it as a restriction. E.g., that an "untyped" object pointer exists and is still useful (in contrast to a real untyped pointer). Of course, you can do the same thing in C++ if, by convention, you use a common ancestor. Your "untyped" pointer then becomes the pointer to that ancestor class. Of course, an Objective-C -> C++ mapping could do just that.
As a side note, I think this philosophy has to do with "big objects", i.e. objects that represent applications, documents, views etc. (MVC is often mentioned in this context). While even there I'm skeptical (do you really ever need a reference to an object of which you don't even know if it's a model or, say, a button?), the C++ idea is rather that almost everything (apart from simple types and arrays) can be an object, including strings, lists, or complex numbers. And I don't think I need (or want) polymorphy between those very different things.
This relates to the previously raised (and unanswered!) question how to declare, e.g. a list of "TFoo" objects. Objective-C, like all pure OOP suggestions I've seen so far, allows for a list of any object. But what if you want, like I do almost every time, a list that contains only objects of a certain type (with compile-time checking)? So far, only templates provide a generic solution AFAICS.
- Message passing. This doesn't translate directly to C++, but it could be done with some extra effort (which, of course, a converter tool could do automatically), such as adding a dispatcher method (virtual in C++ terms) to the "ancestor object", and registering all methods with it (by name, or a hash of the name).
So, AFAICS, it would be possible to implement the language features of Objective-C in a C++ output through a converter tool with moderate effort.
However, the original question seems to be more about binary compatibility to existing Objective-C code, which would probably not be achieved this way.
Frank