Hacker News Reader

Comment by pavlov | Hacker News Reader

This is basically how the Cocoa-Java bridge worked 25 years ago, except of course Java has GC.

The article makes no mention of memory management. ARC is a compiler feature, so I guess this C code makes a ton of calls to an nsobject_release() function for everything allocated in Obj-C world. The code example shown seems to be just leaking the NSString instance.

Which platform doesn't have Clang? Why not allow the Obj-C compiler to take away all that C boilerplate and fragile retain counting gruntwork, and then wrap those calls in a concise C API that provides the exact interface your application needs? I don't really get it.

View on HN

> Why not allow the Obj-C compiler to take away all that C boilerplate and fragile retain counting gruntwork, and then wrap those calls in a concise C API that provides the exact interface your application needs? I don't really get it.

100%. If you’re tying your codebase to Cocoa (or other objc framework), it makes zero sense to avoid Objective-C while also requiring intimate knowledge of Objective-C conventions.

Plus, you’re potentially breaking all sorts of related tooling. Documentation lookup becomes harder. Will Instruments work right? Can you get clang Static Analyzer tips? What about objc-specific compiler warnings? Any time you want to search for code / examples / whatever, you have to translate the symbols. What does it do to a stack trace? Do you get the same deprecation warnings? Does it work correctly if a team member uses a different SDK version, either intentionally or accidentally?

This way you dont have to wrap by hand, and any time Apple releases a new API or makes a change you push a button and have a new wraper. Writing a wrapper also requires someone who knows Objective C.

There are obviously things that could be refined, but for a first release it has proven to be very effective in production.

But using the raw Cocoa Objective-C APIs via a wrapper... also requires someone who knows Objective-C? Because how else are you going to understand the API documentation?

It seems that if you unleash this wrapper onto a C programmer who has never used Cocoa, you'll just be in a world of hurt with unexplained memory leaks and segfaults due to misunderstood object lifetimes.

For example, class factory methods like +[NSString stringWithFormat:] will return an autoreleased instance. How will the C programmer know this convention if they've never used Objective-C?

Practically nobody starts a new project on macOS / iOS that uses manual memory management instead of ARC, so you won't have a lot of documentation when you go down this path. The Apple documentation for the aforementioned stringWithFormat: method doesn't mention (anymore!) that the return value is autoreleased because that doesn't matter with ARC, but makes all the difference for someone using the C wrapper.

>It seems that if you unleash this wrapper onto a C programmer who has never used Cocoa, you'll just be in a world of hurt with unexplained memory leaks and segfaults due to misunderstood object lifetimes.

This is true for every API under the sun. If you just use it without reading the documentation or understanding the design philosophy, you're alyways in a world of hurt.

The same things that are true for Obj-C are true for the wrapper, it just lets you use the API in C. No more, no less.

> If you just use it without reading the documentation or understanding the design philosophy

They literally covered this point for you:

> The Apple documentation for the aforementioned stringWithFormat: method doesn't mention (anymore!) that the return value is autoreleased because that doesn't matter with ARC

It is no secret that documentation surrounding the "old ways" of Apple dev is a pain in the ass to find.

It is not documented on a per method basis. You can see by looking at the name of the method that it does return an auto released instance… this convention is well documented and made ARC possible.

That’s the point. To use this wrapper correctly, you need to know how Objective-C works and you need to be able to read Obj-C code to understand the documentation.

In fact you need to know quite a bit more about Obj-C details than the average iOS programmer because you’re doing manual memory management rather than compiler-assisted ARC (automatic reference counting).

So I don’t really see who this is for. The person who has to learn Obj-C but must pretend not to know it to please the boss who insisted on plain C?

The API documentation is available in the header files. If you were to parse those, I'm pretty sure you could generate the docs for the C API automatically, just as Apple does for Swift. You'd need to do a fair bit of search-and-replace to get the function and type names right, but the API surface is finite and it doesn't change that often. If you were willing to put a good amount of work into a generator, you could get it to a state where it would be able to fully parse all of the Apple SDKs.

There's no magic in ARC, it's all just calls to retain and release that the compiler synthesizes for you automatically. If you have the headers, you can do what it does and figure out which methods return objects that need to be manually released. If you were generating bindings for a language with RAII, like Rust or C++, you could create a bunch of wrapper types and give them destructors, the best you can do for C is adding an extra paragraph in your docs.

The point is: what's the point of wrapping this at all? You can just directly call `[object foo]` instead of doing your own `object_foo()` wrapper just because you want to make the syntax prettier. It's like doing `#define saith printf` -- you're obfuscating your platform-specific code and making it more difficult for people familiar with the platform to understand what's going on. This is subtracting value from your sourcebase, not adding value!

And it doesn't help people who aren't used to Objective-C, because they'll be utterly, hopelessly lost trying to deal with platform-specific features like autorelease pools and Foundation-specific calling conventions. And they won't be able to find docs for your weird syntax.

You cannot remove the platform from the platform specific bits! It will come back to bite you.

Also, you really need to check the memory management situation -- the code samples are leaking memory out the wazoo and it doesn't give confidence that any code using your wrapper isn't doing the same.

I was curious about the leak on NSString too.

When you’re using C, you will have to take care of the retain/release cycle if you allocate by hand objects. The internal of the object should take care of themselves though.

It’s a bit like using unsafe in rust - you’re the one responsible.

I don’t see much of a point of doing it that way. I do prefer working with ObjC with some C in it if need be ;)

Sadly the Java bindings were way easier to use than Obj-C but it undermined Steve's vision.

I think the Oracle v. Google lawsuit (regarding Android’s use of Java) validated Jobs’s intuition that it wasn’t a great idea to have somebody else’s proprietary programming language as a first-party API.

If Java had become the primary language for Cocoa, the path to Cocoa Touch and an iPhone App Store could have been much more complicated.

Did you use them?

I tried to and have _very much_ the opposite opinion about the ease of use.

Yeah, 1000% this. The Java bridge was a catastrophe, and Objective-C worked beautifully with Cocoa.

Oh there were rough edges but mostly because they abandoned them quickly but being able to use a great IDE to write code and have it all autocomplete was way better than having xcode open and the docs trying to figure out the APIs was painful.

Java bridge only existed because at first Apple wasn't sure if the Object Pascal/C++ developer community would embrace Objective-C.

When most of them rushed to adopt Objective-C, there was no reason to keep two stacks around, specially when they were still in the red, bleeding money.

> Which platform doesn't have Clang?

Darwin/PowerPC :(

Couldn't ARC be disabled, and autorelease be used instead?

Autorelease only works if you put the object in the autorelease pool. Some calling conventions also put it in the pool for you but if all you did was manage pools you'd leak memory.

I‘m aware, is that an obstacle?

> if all you did was manage pools you'd leak memory

I‘m not sure what you mean there.

You can't rely solely on autorelease unless you're going to put literally everything in the autorelease pools, which would not be great for performance.

Reply on news.ycombinator.com