Although we can introspect various Obj-C symbols via the Obj-C runtime helpers e.g. objc_getClass, C functions, enums, and other symbols are not introspectable at runtime, as I found in https://github.com/lukaskollmer/objc/pull/43 (you can see in the comments various symbol lookups that failed - NSTitledWindowMask is one of them).
I believe the root of the problem is that bundle.load(), used here:
... does not load any C symbols for the dynamic linker to find. Well, my reasoning may be wrong, but either way, they're not being found in this call (we're throwing an error):
I believe we'd have more success by adopting the approach used by NodObjc to look up symbols, which involves loading the BridgeSupport files, which were specifically designed for use by Objective-C bridges like RubyCocoa and PyObjC.
Alternatively, we may be able to get further on the back of the existing approach by importing Core Foundation and introducing calls to CFBundleGetDataPointerForName and CFBundleGetFunctionPointerForName, but this would turn things into an O(2N) lookup as more and more frameworks are imported (check the data pointer and then the function pointer for each framework we've imported during the app's lifespan), and unlike the BridgeSupport approach, it's not yet tried-and-tested.
Although we can introspect various Obj-C symbols via the Obj-C runtime helpers e.g.
objc_getClass, C functions, enums, and other symbols are not introspectable at runtime, as I found in https://github.com/lukaskollmer/objc/pull/43 (you can see in the comments various symbol lookups that failed -NSTitledWindowMaskis one of them).I believe the root of the problem is that bundle.load(), used here:
https://github.com/lukaskollmer/objc/blob/cc4d6f0cb7475b29cdbf16b5662a3b302e36149b/src/util.js#L28
... does not load any C symbols for the dynamic linker to find. Well, my reasoning may be wrong, but either way, they're not being found in this call (we're throwing an error):
https://github.com/lukaskollmer/objc/blob/cc4d6f0cb7475b29cdbf16b5662a3b302e36149b/src/runtime.js#L48-L58
I believe we'd have more success by adopting the approach used by NodObjc to look up symbols, which involves loading the BridgeSupport files, which were specifically designed for use by Objective-C bridges like RubyCocoa and PyObjC.
Alternatively, we may be able to get further on the back of the existing approach by importing Core Foundation and introducing calls to CFBundleGetDataPointerForName and CFBundleGetFunctionPointerForName, but this would turn things into an O(2N) lookup as more and more frameworks are imported (check the data pointer and then the function pointer for each framework we've imported during the app's lifespan), and unlike the BridgeSupport approach, it's not yet tried-and-tested.