http://code.google.com/p/jskitx/
(Since JSKit was taken)
This is a version 0.2b1, which includes the three patches for performance and "retain cycle breaking". It also includes updates for better exception handling (and passing exception handling between the worlds), as well as the re-org of the sources.
There is also the start of an "auto-generated" CG bridge, but that isn't complete yet (and doesn't compile)
Public svn for JSKit, updates
Thanks for restructuring the code!
I noticed that JSKitBridgeInvocation is still in the JSKitBridgeObject header/source file. Ideally, I'd like to just copy all the code in JSKore into my project. As it stands, I need to copy everything in JSKore + JSKitBridgeObject.{h,m}. Two possible solutions. Put JSKitBridgeInvocation + JSKitBridgeCallFunctionWithSelector() into its own source/header inside the JSKore/ directory. Or just move JSKitBridgeObject source/header inside JSKore/.
My $.02... I'd think option #1 is preferable, since if you're only using JSKore then you don't care about the bridge object. Also, with option #1, it may be worthwhile to move the bridge methods from JSKitInterpreter.m to a category defined in JSKitBridgeObject.{h,m}. This way JSKitInterpreter contains no bridge code unless you want to use bridging.
-Dave
I noticed that JSKitBridgeInvocation is still in the JSKitBridgeObject header/source file. Ideally, I'd like to just copy all the code in JSKore into my project. As it stands, I need to copy everything in JSKore + JSKitBridgeObject.{h,m}. Two possible solutions. Put JSKitBridgeInvocation + JSKitBridgeCallFunctionWithSelector() into its own source/header inside the JSKore/ directory. Or just move JSKitBridgeObject source/header inside JSKore/.
My $.02... I'd think option #1 is preferable, since if you're only using JSKore then you don't care about the bridge object. Also, with option #1, it may be worthwhile to move the bridge methods from JSKitInterpreter.m to a category defined in JSKitBridgeObject.{h,m}. This way JSKitInterpreter contains no bridge code unless you want to use bridging.
-Dave
Option #1 seems the better solution - I'm still not convinced what to do with JSKitBridgeInvocation, though. It probably should be beefed up a bit to handle NSInvocation based calls (as well as just target + selector + NSArray of parameters), but that may drag in more of the bridging code.
(And at some point, using ffi will be an option and if it can encapsulate that as well...)
And, as a matter of fact, I've just checked it in. I've also pulled the bridge and package registration code off into bridge and package files as categories, so hopefully JSKore is now "pure".
It will eventually be extended to include NSInvocation based calls, but maybe not this morning
(And at some point, using ffi will be an option and if it can encapsulate that as well...)
And, as a matter of fact, I've just checked it in. I've also pulled the bridge and package registration code off into bridge and package files as categories, so hopefully JSKore is now "pure".
It will eventually be extended to include NSInvocation based calls, but maybe not this morning