Swiftネイティブ基本クラスまたはNSObject

私はSwiftでいくつかのisa swizzlingをテストし、NSObjectがスーパークラス（直接またはさらに上位）である場合、または '@objc'装飾を使用する場合にのみ機能することを発見しました。それ以外の場合は、C ++のような静的およびvtable-dispatchスタイルに従います。

Cocoa / NSObject基本クラスなしでSwiftクラスを定義するのは正常ですか？私が心配しているのであれば、これは、メソッドのインターセプトやランタイムイントロスペクションなど、Objective-Cのダイナミズムの大部分を先導することを意味します。

動的な実行時の動作は、プロパティオブザーバー、コアデータ、アスペクト指向プログラミング、高次メッセージング、分析およびロギングフレームワークなどの機能の中心に位置しています。

Objective-Cのメソッド呼び出しスタイルを使用すると、メソッド呼び出しに約20のマシンコードオペランドが追加されるため、特定の状況（小さなボディを持つメソッドへの多くの厳密な呼び出し）では、C ++スタイルの静的およびvtableディスパッチのパフォーマンスが向上します。

しかし、一般的な95-5ルール（パフォーマンス向上の95％はコードの5％のチューニングから得られる）を考えると、強力な動的機能から始めて、必要に応じて強化することは理にかなっていますか？

NSObjectのサブクラスであるSwiftクラス：

• それ自体がObjective-Cクラスです
• objc_msgSend()メソッドの（ほとんどの）呼び出しに使用する
• メソッドの実装（のほとんど）にObjective-Cランタイムメタデータを提供する

NSObjectのサブクラスではないSwiftクラス：

• Objective-Cクラスですが、NSObject互換性のために実装されているメソッドはほんの一握りです
• objc_msgSend()メソッドの呼び出しには使用しない（デフォルト）
• メソッドの実装にObjective-Cランタイムメタデータを提供しない（デフォルト）

SwiftでNSObjectをサブクラス化すると、Objective-Cランタイムの柔軟性だけでなく、Objective-Cパフォーマンスも得られます。Objective-Cの柔軟性が必要ない場合は、NSObjectを回避するとパフォーマンスが向上します。

編集：

Xcode 6ベータ6では、動的属性が表示されます。これにより、メソッドで動的ディスパッチを使用するようにSwiftに指示できるため、インターセプトがサポートされます。

public dynamic func foobar() -> AnyObject {
}

また、SwiftクラスをNSObjectに基づいていると、コーディングのバグを隠す可能性のある予期しない実行時の動作が発生することもわかりました。例を示します。

この例では、NSObjectに基づいていないため、コンパイラーはtestIncorrect_CompilerShouldSpotでエラーを正しく検出し、「... 'MyClass'は 'MirrorDisposition'に変換できません」と報告します。

class MyClass {
  let mString = "Test"

  func getAsString() -> String {
    return mString
  }

  func testIncorrect_CompilerShouldSpot() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject == myString) {
        // Do something
      }
  }

  func testCorrect_CorrectlyWritten() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject.getAsString() == myString) {
        // Do something
      }
  }
}

この例では、NSObjectに基づいていますが、コンパイラーは testIncorrect_CompilerShouldSpotでエラーを検出しません。

class myClass : NSObject {
  let mString = "Test"

  func getAsString() -> String {
    return mString
  }

  func testIncorrect_CompilerShouldSpot() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject == myString) {
        // Do something
      }
  }

  func testCorrect_CorrectlyWritten() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject.getAsString() == myString) {
        // Do something
      }
  }
}

道徳は、本当にしなければならないNSObjectのみに基づいていると思います！

言語リファレンスによれば、クラスが標準のルートクラスをサブクラス化する必要はないため、必要に応じてスーパークラスを含めたり省略したりできます。

クラス宣言からスーパークラスを省略しても、暗黙の基本スーパークラスは割り当てられないことに注意してください。これは基本クラスを定義します。これは実質的に独立したクラス階層のルートになります。

言語リファレンスから：

Swiftクラスは、ユニバーサルベースクラスを継承しません。スーパークラスを指定せずに定義したクラスは、自動的にベースクラスになり、その上に構築します。

superスーパークラスのないクラス（つまり、基本クラス）から参照しようとすると、コンパイル時エラーが発生します。

'super' members cannot be referenced in a root class

Swiftのデータの大部分はそうではないと思いますobjc。Objective Cインフラストラクチャと通信する必要のある部分のみが、そのように明示的にマークされます。

ランタイムイントロスペクションがどの程度言語に追加されるかはわかりません。メソッドのインターセプトは、メソッドが明示的に許可した場合にのみ可能になる可能性があります。これは私の推測ですが、実際にどこに向かっているのかを知っているのはApple内の言語デザイナーだけです。

以下はAppleのSwift-eBookからコピーしたもので、質問に対する適切な回答を示しています。

基本クラスの定義

別のクラスから継承しないクラスは、基本クラスと呼ばれます。

Swiftクラスは、ユニバーサルベースクラスを継承しません。スーパークラスを指定せずに定義したクラスは、自動的にベースクラスになり、その上に構築します。

参照

正常です。Swiftの設計目標を見てください。目標は、プログラミング問題の巨大なクラスをなくすことです。メソッドのスウィズリングは、おそらくSwiftで実行したいことの1つではありません。