Swift isa pointer remapping or other supported method swizzling

前端 未结 2 1402
北恋
北恋 2020-12-30 07:17

Do Swift classes have something like an isa pointer that can be remapped?

We\'ve seen that Swift uses a more static method dispatch than objective-C, which (unless

相关标签:
2条回答
  • 2020-12-30 08:13

    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).

    0 讨论(0)
  • 2020-12-30 08:14

    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.

    0 讨论(0)
提交回复
热议问题