> On Aug 18, 2015, at 5:19 PM, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> But, in my own defense, I was looking for verification first that the
> mechanism is safe in 100% pure Swift. The next thing to verify is whether
> it’s safe with an @objc base class in Swift. Only if both those things are
> safe does it make any sense to wonder if an Obj-C base class is safe.
Currently, the Swift runtime hasn’t stabilized yet, and it’s pretty unlikely
that any system frameworks will be written in it until it is. So currently,
you’re going to be recompiling everything every time, and your code will all
have access to all Swift methods, public and private. So with pure Swift, it
shouldn’t be an issue one way or another until Apple starts shipping a Swift
runtime with the OS, at which point we can do a new test.
…oh heck, let’s test it now.
Framework code:
import Foundation
public class BaseClass {
public init() {}
public func foo() {
print("Foo called in library")
}
}
App code:
import MyFramework
class DerivedClass: BaseClass {
func bar() {
print("Bar called in app")
}
}
let obj = DerivedClass()
obj.foo()
Output:
Foo called in library
New framework code:
public class BaseClass {
public init() {}
public func foo() {
print("Foo called in library")
self.bar()
}
internal func bar() {
print("Bar called in library")
}
}
Results without recompiling:
Foo called in library
Bar called in app
Wat.
Results after a recompile look okay:
Foo called in library
Bar called in library
However, for more fun times, I tried deleting bar() from BaseClass and running
the app again without recompiling. I got:
dyld: Symbol not found: __TFC11MyFramework9BaseClass3barfS0_FT_T_
Referenced from:
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/new
test.app/Contents/MacOS/new test
Expected in:
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/MyFramework.framework/Versions/A/MyFramework
in
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/new
test.app/Contents/MacOS/new test
If bar() is declared as private instead of internal, the library’s copy of bar
gets called each time, but the crash still happens if I remove the method from
the framework without recompiling the app.
So, in summary: Swift doesn’t fix the problem Objective-C has, and it adds a
new one.
> However, the test you did doesn’t give much cause for optimism. I suppose
> *selectors* would have to be namespaced to solve the problem for the Obj-C
> runtime, wouldn’t it? For compatibility reasons, that seems unlikely, which
> makes it unlikely that this problem will ever be solved for Cocoa frameworks.
You could do something like @objc(MyObnoxiousPrefix_foo), and if you were only
going to call it from Swift anyway, it wouldn’t ugly up your code at all. The
problem above would still remain, of course (although in all seriousness, I’d
be kinda surprised if it stayed that way - Swift is clearly still in formative
stages).
Charles
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
