Earlier quoted context omitted.
You last sentence is a bit far-fetched.
It is an elegant weapon, for a more civilized age
If you want to shoot your own foot sure!
Apple's new Objective-C to Javascript Bridge
71–80 of 110 posts
Re: Apple's new Objective-C to Javascript Bridge
#72Re: Apple's new Objective-C to Javascript Bridge
#73This will probably be Mac-only. It will not appear on iOS unless Apple also ships BridgeSupport on iOS. BridgeSupport is needed for binding all the Obj-C parts that don't have introspection capabilities (like the C parts). This is how most of the other full feature bridges work, PyObjC, RubyCocoa/MacRuby, LuaCocoa. Otherwise you are hamstrung anytime you need to deal with something like a C struct (e.g. NSPoint).
As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself.
You don't necessarily need BridgeSupport to call out to Objective-C.
Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge after Laurent Sansonetti left Apple. A shame.
[1] - For example, http://merbist.com/2011/02/19/bridgesupport-build/ . The chapter referenced from O'Reilly's excellent MacRuby book does a better job of explaining the whole process.
Re: Apple's new Objective-C to Javascript Bridge
#74Re: Apple's new Objective-C to Javascript Bridge
#75This just seems like an evolution of the existing Obj-C/JS bridge (namely, WebScriptObject https://developer.apple.com/library/mac/#documentation/Cocoa... and WebScripting protocol https://developer.apple.com/library/mac/#documentation/Cocoa... ). The main (very welcome) advancement seems to be that they've pushed this capability down from WebKit into JSCore. Today you can basically already do everything that's being…
Good catch, I hadn't seen that before. It definitely looks like WebScript and the new JavaScriptCore API are strongly related. It's interesting how hard the WebScript stuff is to find without knowing the name, it didn't turn up in any of my Googling when researching the post.
The fact that it's a refactoring (even a very nice one, as it seems to be) rather than a brand new API does make it less likely that Apple has any particular future plans for the API, which in turn make much of the speculation in the post even more speculative. I'm going to make an update to the post with a link to WebScript as well as a bit of additional commentary.
Re: Apple's new Objective-C to Javascript Bridge
#76This will probably be Mac-only. It will not appear on iOS unless Apple also ships BridgeSupport on iOS. BridgeSupport is needed for binding all the Obj-C parts that don't have introspection capabilities (like the C parts). This is how most of the other full feature bridges work, PyObjC, RubyCocoa/MacRuby, LuaCocoa. Otherwise you are hamstrung anytime you need to deal with something like a C struct (e.g. NSPoint).
As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself. You don't necessarily need BridgeSupport to call out to Objective-C. Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge aft…
BridgeSupport also supplies .dylibs containing inline functions/macros that don't have symbols/linkage in the main framework.
While it is possible to workaround the lack of BridgeSupport, if Apple doesn't supply it, most developers are not going to go through the effort of using it. And if Apple doesn't supply it on iOS, they aren't going to make life nice for developers doing this (continue bans on dynamic libraries for loading the .dylib containing missing symbols, on mprotect which is horribly useful for things like subclassing and block generation and JIT).
I don't know where the source went. I'm sad to hear that. If you find a copy, let me know.
Re: Apple's new Objective-C to Javascript Bridge
#77Earlier quoted context omitted.
Closures + Lexical Scoping + Prototypical Inheritance makes for a pretty great language IMHO.
Those things are indeed nice, but they can't defend against the other insanities that come in the box with them.
All languages have crap.
C? Buffer overflows, manual memory management, header files, severely lacking standard libraries, crap support for most modern idioms, etc etc.
C++? Tons of edge cases, template madness, unbelievable large language spec, etc etc.
Python? Python 2 - 3 dichotomy, crappy concurrency / parallelism support, , strict on whitespace, standard libs in various stages of cruft and abandonment, no proper closures, CPU bound for lots of interesting problems necessitating bilingual development with C extensions or the use of hacks such as Cython etc.
You can find a similar list for everything, from Lisp to Haskell.
Javascript "insanities" are no big deal. People have been creating large apps (including porting stuff like THE WHOLE BLOODY QT TOOLKIT to it) in it with no problems. Once you know them, you can work around them.
A huge install base, huge number of programmers, easy syntax, powering the internet, lispy-flexibility, and the fastest interpreters this side of the JVM are enough benefits to counter some crappy coercion rules and FP only math bizarreness.
Re: Apple's new Objective-C to Javascript Bridge
#78I never had a big problem with Obj-C. It felt like any other language other than having to manually manage memory. The problem I struggled with was Cocoa as a whole. It may no longer be the case but not too long ago, there was a lack of consistency between the different APIs / SDKs. Most would written and accessed with Obj-C. A few would still be in Ansi-C. For someone who isn't a C expert, this just killed me. Does…
Yeah, like the iOS contacts API. I really like Objective C. (I better since I write it full time, lol)
Re: Apple's new Objective-C to Javascript Bridge
#79My guess is that this would be fast enough to build almost any Mac app and many iOS apps. The bigger question for me is, how gross would it be to deal with the "Objective-C-ness" of the Cocoa APIs through JavaScript?
It's important to remember that Apple shipped both the Ruby and Python Objective-C bridges in ~10.5 era OS X. You can (and I have) written OS X native software in Python; it wasn't super pretty, but the concepts mapped across reasonably well. So I wouldn't take this as necessarily the sign of a shift in anything.
They used to have a Java bridge as well[1]. WebObjects moved from Objective C to Java at some point in the early '00s.
Re: Apple's new Objective-C to Javascript Bridge
#80How does this compare to cocos2d/zynga's JSB? The JavaScript Bridge
Cocos2d uses SpiderMonkey, not JavaScriptCore.