Experimental/WIP
- Filter enum item names to simplify them
- Generate code to allow objects to extend others and conform to protocols (only single protocol supported for now)
- Testing, etc.
- Block handling
- bit_sets
These bindings are generated automatically by a private tool which uses libClang to generate C/C++/Objective-C type data, which is then used by a different private tool to generate bindings for Odin (which was adapted from originally generating C# bindings).
As such, all of the types in specified framework headers are exported, unless explicitly ignored or modified in the export specification (see darwodin.yml)
Only a few frameworks have currently been generated. Also, some other frameworks have been amalgamated into "Cocoa" that are not necessarily part of Cocoa (Security, for example). This is for simplicity for the time being.
For simplicity, the bindings are currently generated from a single header and specification file which exports multiple frameworks at the same time (albeit into separate modules). This means that method categories defined in a framework external to the a class's defining framework get included in the framework to which the class belong.
This is likely subject to change, but more work is required to exclude symbols already exported from other frameworks. The manner to handle how categories are bound also needs to be determined.
The automatically generated bindings support explicit overload of procedures, and they are generated whenever possible.
Because Odin seems to disallow explicit overloads when the arguments of any 2 procedures match their types exactly, I've opted to not resolve most typedefs to their underlying primitive types, as this allowed for a much lower overload conflict. Therefore they have been kept as distinct types.
There are cases where the overload conflicts still happen, in such cases the overloads are not generated.
Currently only basic framework prefix enum filtering is being applied, however some more robust filters can be applied to simplify the enum item names, which ought to be implemented in the near future.
There are cases when a class method shares the same name with an instance method. When this conflict occurs, the class method will have the suffix "Static" applied to its name.
When overload methods have the same selector, excluding a trailing ':`, then its last parameter's name will be appended to the method name to avoid conflict.
Objective-C protocols that share the same name with an Objective-C class have their name modified by applying a suffix of "Protocol" to their type name (e.g. the protocol NSObject becomes NSObjectProtocol).
When extending objects you can currently only conform to a single protocol per object extension.
va_list has been added as a false type for the time being to test complete method generation.
Although generics data is generated for NSObjects from the type data tool, it is not used when generating the Odin code.