“Listen: David Smith has come unstuck in time.” — Kurt Vonnegut, probably

Cohost bonus feature: 80% less professional

You must log in to comment.

in reply to @Catfish-Man's post:

Really excited to see this! One thing though that I’m confused about: What does this mean for the obj-c version of Foundation? Will it exist as a parallel implementation on macOS, or will it somehow be built atop the new swift implementation? Admittedly the latter seems a bit hard to pull off- but maybe there is a plan?

Good hint! :D I was asking myself how parallel class hierarchies would work, eg. what would it mean to call "super". But maybe swift foundation will be primarily built around structs and protocols, which may make this a non-issue. Looking forward to find out!

Yeah, but what I meant was a situation like the following:

/// Implements Foundation functionality
open class A {
    open func foo() {}
    open func bar() {
        self.foo()
    }
}

/// Obj-C wrapper around A
@objc open class NS_A: NSObject {
    // wraps an A that implements functionality
    let a = A()

    @objc func foo() {
        self.a.foo()
    }

    @objc func bar() {
        self.a.bar()
    }
}

@objc class CustomA: NS_A {
    override func foo() {
        /* do custom foo */
    }
}

// Expects custom self.foo() to be called.
CustomA().bar()

In this naive implementation, the overridden foo method would not be called, violating this made up API contract. Even more complex scenarios can be dreamed up, involving multiple open subclasses, etc...

Clearly, this can't be how the bridging to obj-c will be implemented! So looking forward to find out how these kind of scenarios will be handled. :)