ObjC: Split generation into internals and object-oriented API?

[dcharkes]

The mental model that I have for C APIs is that ffigen generates a low level API (with lots of Pointers and only top level functions), and that a user manually wraps that in an object-oriented API. The object-oriented API does not expose any dart:ffi classes, only normal Dart classes. (See https://www.youtube.com/watch?v=2MMK7YoFgaA for the mental model.)

Now, because Objective C is already object-oriented, we can immediately generate an object-oriented API.

https://github.com/dart-lang/ffigen/pull/333#discussion_r855843903

I wonder if it would make sense to make ffigen for objective C generate two files instead of one:

1. The low-level bindings: operates on Pointers a lot.
2. The object-oriented API. This does not expose any dart:ffi types (except Pointer<NativeFunction<...>> for callbacks).

The benefits would be that we:

1. Don't have to make all generated methods that we don't want to expose to the user private. We just don't expose the low level bindings.
2. The public object-oriented API would be clearly separated from low-level bindings. This would likely increase the ease of using it.

However, maybe this doesn't work because an ObjectiveC programmer uses the object-oriented and low level things intermixed.

@brianquinlan since you are the main user right now, what are your thoughts on this?

@liamappelbe WDYT? (And would it make sense to have two layers in the implementation as well?)

[liamappelbe]

This is a conceptually appealing idea, but I see some issues.

• Static ObjC functions are somewhat high-level (in that the user shouldn't feel like they're getting their hands dirty when calling them), but would still live in the NativeLibrary in the low-level file.
• dart-lang/native#308 is about making these static functions use the wrapper types rather than the pointers, which won't work if the wrappers are in another file. Maybe a fix would be to put wrappers around all the static functions in the high-level file, and do the interface wrapping/unwrapping there? Seems like a lot of wrapping though.
• Whether or not the object-oriented API expose the underlying details is orthogonal to whether it's in the same file or not.

Relatedly, maybe it would help usability if we generate some comments at the top of the file that lists all the functions/classes/methods, so the user doesn't have to scroll through a huge generated file? Or do we assume users are just going to run dartdoc or something?

[liamappelbe]

package:objective_c now owns all the low level bindings, so this is done.