Swift isa pointer remapping or other supported method swizzling

I can't answer your question about swift "isa" equivalent, but I think I know part of the answer to your underlying question.

Property Observers seem to be the built-in means for the Observer Pattern. Instead of runtime discovery of "type" (RTTI, what-have-you) it is woven in explicitly.

From 'The Swift Programming Language' page 345:

Property observers observe and respond to changes in a property's value. Property observers are called every time a property's value is set, even if the new value is the same as the property's current value.

You can add property observers to any stored properties you define, apart from lazy stored properties. You can also add property observers to any inherited property (whether stored or computed) by overriding the property within a subclass.

You have the option to define either or both of these observers on a property:

• willSet is called just before the value is stored.
• didSet is called immediately after the new value is stored.

I am not sure how this is all going to work out, but I am intrigued.

Relying on run-time type discovery also seems to run counter to strong static type orthodoxy.

It looks like both method exchanging and the isa pointer remapping technique only works if the Swift class has NSObject as a super-class (either directly or further up). It does not currently work, when the Swift class has no super-class or some other non-Foundation base class.

The following test shows this:

Class: Birdy

class Birdy: NSObject {    
    func sayHello()
    {
        print("tweet tweet")
    }    
}

Class: HodorBirdy

class HodorBirdy: Birdy {

    override func sayHello()
    {
        super.sayHello()
        print("hodor hodor")
    }
}

Test:

func testExample() {        
    let birdy : Birdy = Birdy()
    object_setClass(birdy, HodorBirdy.self)
    birdy.sayHello();
}

And the output was as expected:

tweet tweet
hodor hodor

In this test both the base-class and sub-class were created in advance. Though they could also be created dynamically using the Objective-C runtime as long as the class has NSObject as an ancestor.

When a Swift class does not derive from the Objective-C foundation, then the compiler will favor static- or vtable-based dispatch, therefore its not clear how method interception will work at all in this case!

Unless the language/compiler make a specific allowance for it, we'll be foregoing dynamism in favor of performance. (Interception, which is the foundation of 'dynamic' behaviors can either be done at compile-time or run-time. In the case of static- or vtable-dispatch without a virtual machine, only compile-time applies).