3 ms·

Every Objective-C class/object is a C structure. Every Objective-C message send is actually a C function call (objc_msgSend). Every Objective-C method is actual

by jcizzle 15y ago

Every Objective-C class/object is a C structure. Every Objective-C message send is actually a C function call (objc_msgSend). Every Objective-C method is actually a C function definition. So, to the contrary, every Cocoa project is just using C functions, types and using the ObjC runtime. The point you are trying to make is that porting an ObjC application to another language would be difficult because of the syntax of the language, notably, the interspersing of arguments within the method name. My point is that this has zero relevance to adopting a new application-level API. An application-level API hooks into OS-level calls (which are not ObjC), which gets turned into assembly, which gets turned into machine code. The only way Cocoa applications would no longer run is if the Cocoa library could no longer bridge the the operating system or if they intentionally did not ship the Cocoa library. Thus, creating a new application-level API would deprecate Cocoa, but wouldn't render those applications useless. Clearly, a company would have to transition to the new language/API. However, once again, the syntax of ObjC would not make it any more difficult or easy to make this transition compared to any other language. And this did not stop Apple 10 years ago, so I don't envision this stopping them again (C Carbon -> ObjC Cocoa; note that you can still make Carbon calls on Mac OS X).

makecheck 15y ago
All kinds of things compile down to assembly. Binary compatibility between two programs doesn't say anything about how easy it would be to translate their designs into other languages (which is often a new way of thinking), or different standard libraries. Many approaches are possible, few are worth the effort. If Apple proposed a new language that didn't support message-passing syntax, and the only way to keep Cocoa dependencies working was with a pile of objc_msgSend() calls and other low-level wrappers, developers would just laugh at them. A single line of Objective-C often contains 3 or 4 pairs of square brackets, and objc_msgSend()-ifying that alone would be a nightmare even in the short term and even with a code generator. That's why I said, the new language has to follow the same calling conventions. Fundamentally, whenever I see "setFoo:x toBar:y withBaz:z", I should be able to either leave that alone or do very little to that line of code. Carbon-to-Cocoa was feasible because Objective-C is a superset of C (plus the libraries did share some things, like free casting between the CFStringRef and NSString* types). Not only that, but there's a compiler for Objective-C++. It was very easy to adopt. So to follow the Carbon-to-Cocoa model, Apple needs a new language that's a superset of Objective-C. And that's actually something I'd like to see.

by jcizzle 15y ago

makecheck 15y ago

All kinds of things compile down to assembly. Binary compatibility between two programs doesn't say anything about how easy it would be to translate their designs into other languages (which is often a new way of thinking), or different standard libraries. Many approaches are possible, few are worth the effort. If Apple proposed a new language that didn't support message-passing syntax, and the only way to keep Cocoa dependencies working was with a pile of objc_msgSend() calls and other low-level wrappers, developers would just laugh at them. A single line of Objective-C often contains 3 or 4 pairs of square brackets, and objc_msgSend()-ifying that alone would be a nightmare even in the short term and even with a code generator. That's why I said, the new language has to follow the same calling conventions. Fundamentally, whenever I see "setFoo:x toBar:y withBaz:z", I should be able to either leave that alone or do very little to that line of code. Carbon-to-Cocoa was feasible because Objective-C is a superset of C (plus the libraries did share some things, like free casting between the CFStringRef and NSString* types). Not only that, but there's a compiler for Objective-C++. It was very easy to adopt. So to follow the Carbon-to-Cocoa model, Apple needs a new language that's a superset of Objective-C. And that's actually something I'd like to see.