3 ms·

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

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.

pavlov 3y ago
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.
- LuckyBlade 3y ago
  >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.
  - Klonoar 3y ago
    > 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.
    - justmedep 3y ago
      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.
  - pavlov 3y ago
    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?
- miki123211 3y ago
  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.
KerrAvon 3y ago
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.

pavlov 3y ago

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.

LuckyBlade 3y ago
>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.
- Klonoar 3y ago
  > 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.
  - justmedep 3y ago
    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.
- pavlov 3y ago
  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?
miki123211 3y ago
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.

KerrAvon 3y ago

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.