Hacker News Reader

Comment by birdymcbird | Hacker News Reader

Someone knowing existing pattern help me understand this. right now when i use these “foundation” apis in swift it is doing c call? so they rewriting now the c code in swift? (dont do ios or mac code so now sure)

me dont understand what make it faster now. i once wrote some jni code to call c++ library from java. does mean there some similar code to do cross language call? they get rid of it and so things now faster?

offtopic but debugging crashes in c++ over jni call was super hard. logs not work and me not figure out how to fix. wonder if they had similar “troubles” and this make everything easier :)

always feel skeptical when seeing large code base have “rewrite”. try many time in me career thinking there good reasons but super hard and not best value in end

View on HN

It's a lot of obj-c/c on apple and syscalls on other platforms, I think the biggest point its to get rid of annoying obj-c calls and make it fully cross platform as its a nightmare for both safety and performance in many cases to call objc.

Most of Foundation on Darwin used to call into Objective-C code. This is going to be replaced with Swift code while keeping the API the same.

Conversely, will existing Obj-C (and hybrid Swift/Obj-C) apps be able to call the new Swift Foundation?

And will it be binary-compatible with existing apps, or will Apple just ship a separate compatibility version of Foundation for use by legacy apps?

Yes, it’ll be binary compatible.

i don't understand how a compiled language like swift can be binary compatible with a dynamic one like objc. How are they going to implement method swizzling on NSObject for example ?

Swift and Obj-C are both compiled languages, and also dynamic in the sense that they allow a lot of runtime introspection and dynamic dispatch.

They're already binary compatible, in the sense that you can call compiled Obj-C classes from Swift apps (of course), and also - with some restrictions - call compiled Swift code from Obj-C.

In fact, you can "swizzle" methods in Swift just like in ObjC, on classes derived from NSObject:

https://medium.com/@valsamiselmaliotis/method-swizzling-in-s...

What you’re doing in this medium post is call the objc runtime from swift and take advantage from swift <-> objc bridging. This does not work if the class you’re trying to swizzle is a pure swift class. For a reason : swift is mostly static dispatch, whereas objc is pure dynamic dispatch (taking its root from smalltalk).

This means code that tried to swizzle foundation types, assuming foundation is developped in objc, will not work anymore once foundation is using a pure swift implementation.

If Foundation is to retain binary compatibility with Obj-C, then it will by necessity still be using the Obj-C runtime, with Foundation types still extending NSObject, and thus swizzling should still work as before.

The alternative would be for Apple to break compatibility with old Obj-C apps, instead shipping a compatibility version of Foundation.framework which old apps would continue to link against. But it sounds like they're not going that route.

Yet using the objc runtime defeats the purpose of being easier to port to other platforms.

Reply on news.ycombinator.com