Швидкий рідний базовий клас або NSObject

Я перевірив, що Swift шифрує Іса , і виявив, що він працює лише тоді, коли NSObject - це суперклас (безпосередньо чи далі вгору), або використовуючи прикрасу '@objc'. В іншому випадку він буде дотримуватися статичного та vtable-диспетчерського стилів, як C ++.

Чи нормально визначати клас Swift без базового класу Cocoa / NSObject? Якщо мене це турбує, це означає, що більша частина динамізму об'єктивності-С, наприклад перехоплення методів та самоаналіз часу виконання.

Динамічна поведінка під час роботи лежить в основі таких функцій, як спостерігачі власності, основні дані, орієнтоване на аспекти програмування , обмін повідомленнями вищого порядку , аналітичні та журнальні системи тощо.

Використання стилю виклику методу Objective-C додає близько 20 операндів машинного коду до виклику методу, тому в певних ситуаціях ( багато жорстких дзвінків до методів із невеликими тілами ) статична та віртуальна диспетчеризація стилю C ++ може працювати краще.

Але враховуючи загальне правило 95-5 ( 95% підвищення продуктивності відбувається від настройки 5% коду ), чи не має сенсу починати з потужних динамічних функцій і загартовувати там, де це необхідно?

Класи Swift, які є підкласами NSObject:

• є самими класами Objective-C
• використовувати objc_msgSend()для викликів (більшість) своїх методів
• забезпечити метадані об’єктів виконання C (Objective-C) для більшості реалізацій їх методів

Класи Swift, які не є підкласами NSObject:

• є класами Objective-C, але реалізують лише декілька методів сумісності NSObject
• не використовувати objc_msgSend()для викликів їх методів (за замовчуванням)
• не надавати метадані об’єкта виконання Cube Objective-C для їх реалізації (за замовчуванням)

Підкласифікація NSObject в Swift отримує гнучкість виконання Objective-C, але і продуктивність Objective-C. Уникнення NSObject може підвищити продуктивність, якщо вам не потрібна гнучкість Objective-C.

Редагувати:

З Xcode 6 beta 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 справді знають, куди вони насправді прямують.

З Swift-eBook від Apple скопійовано наступне та дає відповідну відповідь на ваше запитання:

Визначення базового класу

Будь-який клас, який не успадковує інший клас, відомий як базовий клас.

Класи Swift не успадковують від універсального базового класу. Класи, які ви визначаєте, не вказуючи суперклас, автоматично стають базовими класами, на яких ви будете будуватись.

Довідково

Це нормально. Подивіться на цілі дизайну Swift: мета полягає в тому, щоб величезні класи проблем програмування зникли. Швидкість методу - це, мабуть, не одна з речей, якими ви хочете займатися зі Свіфтом.