Classe base nativa Swift o NSObject

Ho provato alcuni isa swizzling con Swift e ho scoperto che funziona solo quando NSObject è una superclasse (direttamente o più in alto) o utilizzando la decorazione "@objc". Altrimenti seguirà uno stile di invio statico e vtable, come C ++.

È normale definire una classe Swift senza una classe base Cocoa / NSObject? Se sono preoccupato, questo significa rinunciare a gran parte del dinamismo di Objective-C, come l'intercettazione del metodo e l'introspezione in fase di esecuzione.

Il comportamento dinamico in fase di esecuzione è al centro di funzionalità come osservatori di proprietà, dati di base, programmazione orientata agli aspetti , messaggistica di ordine superiore , framework di analisi e registrazione e così via.

L'uso dello stile di invocazione del metodo di Objective-C aggiunge circa 20 operandi del codice macchina a una chiamata di metodo, quindi in determinate situazioni ( molte chiamate strette a metodi con corpi piccoli ) l'invio statico e vtable in stile C ++ può funzionare meglio.

Ma data la regola generale 95-5 (il 95% dei guadagni in termini di prestazioni proviene dalla messa a punto del 5% del codice ), non ha senso iniziare con le potenti funzionalità dinamiche e rafforzare dove necessario?

Classi Swift che sono sottoclassi di NSObject:

• sono classi Objective-C stesse
• utilizzare objc_msgSend()per le chiamate alla (maggior parte dei) metodi
• fornire metadati di runtime Objective-C per (la maggior parte delle) implementazioni dei metodi

Classi Swift che non sono sottoclassi di NSObject:

• sono classi Objective-C, ma implementano solo una manciata di metodi per la compatibilità con NSObject
• non utilizzare objc_msgSend()per le chiamate ai loro metodi (per impostazione predefinita)
• non fornire metadati di runtime Objective-C per le loro implementazioni di metodo (per impostazione predefinita)

La creazione di sottoclassi di NSObject in Swift offre flessibilità di runtime Objective-C ma anche prestazioni Objective-C. Evitare NSObject può migliorare le prestazioni se non è necessaria la flessibilità di Objective-C.

Modificare:

Con Xcode 6 beta 6, viene visualizzato l'attributo dinamico. Questo ci consente di indicare a Swift che un metodo dovrebbe utilizzare l'invio dinamico e quindi supporterà l'intercettazione.

public dynamic func foobar() -> AnyObject {
}

Ho anche scoperto che se basavo una classe Swift su NSObject, vedevo un comportamento inaspettato in fase di esecuzione che poteva nascondere bug di codifica. Ecco un esempio.

In questo esempio, dove non ci basiamo su NSObject, il compilatore individua correttamente l'errore in testIncorrect_CompilerShouldSpot, riportando "... 'MyClass' non è convertibile in '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
      }
  }
}

In questo esempio, dove ci basiamo su NSObject , il compilatore non individua l'errore in 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
      }
  }
}

Immagino che la morale sia, l'unica base su NSObject dove devi davvero!

In base al linguaggio di riferimento, non è necessario che le classi sottoclasse alcuna classe radice standard, quindi è possibile includere o omettere una superclasse secondo necessità.

Si noti che l'omissione di una superclasse dalla dichiarazione della classe, non assegna una superclasse di base implicita di alcun tipo. Definisce una classe base, che diventerà effettivamente la radice di una gerarchia di classi indipendente.

Dalla lingua di riferimento:

Le classi Swift non ereditano da una classe base universale. Le classi definite senza specificare una superclasse diventano automaticamente classi base su cui costruire.

Il tentativo di fare riferimento superda una classe senza una super classe (cioè una classe base) risulterà in un errore in fase di compilazione

'super' members cannot be referenced in a root class

Credo che la stragrande maggioranza dei dati Swift non lo sarà objc. Solo le parti che devono comunicare con l'infrastruttura Objective C saranno esplicitamente contrassegnate come tali.

Fino a che punto l'introspezione in fase di esecuzione verrà aggiunta alla lingua, non lo so. L'intercettazione del metodo sarà probabilmente possibile solo se il metodo lo consente esplicitamente. Questa è la mia ipotesi, ma solo i progettisti di linguaggi all'interno di Apple sanno davvero dove stanno andando davvero.

Quanto segue viene copiato dallo Swift-eBook di Apple e fornisce una risposta appropriata alla tua domanda:

Definizione di una classe base

Qualsiasi classe che non eredita da un'altra classe è nota come classe base.

Le classi Swift non ereditano da una classe base universale. Le classi definite senza specificare una superclasse diventano automaticamente classi base su cui costruire.

Riferimento

È normale. Guarda gli obiettivi di progettazione di Swift: l'obiettivo è far sparire enormi classi di problemi di programmazione. Il metodo swizzling probabilmente non è una delle cose che vuoi fare con Swift.