Classe base nativa Swift ou NSObject

Eu testei alguns isa swizzling com Swift e descobri que só funciona quando NSObject é uma superclasse (diretamente ou mais acima), ou usando a decoração '@objc'. Caso contrário, ele seguirá um estilo de envio estático e vtable, como C ++.

É normal definir uma classe Swift sem uma classe base Cocoa / NSObject? Se estou preocupado, isso significa renunciar a muito do dinamismo do Objective-C, como a interceptação de método e a introspecção em tempo de execução.

O comportamento dinâmico em tempo de execução está no centro de recursos como observadores de propriedade, dados centrais, programação orientada a aspectos , mensagens de ordem superior , estruturas analíticas e de registro e assim por diante.

Usar o estilo de invocação de método de Objective-C adiciona cerca de 20 operandos de código de máquina a uma chamada de método, portanto, em certas situações ( muitas chamadas apertadas para métodos com corpos pequenos ), o despacho estático e vtable do estilo C ++ pode ter um desempenho melhor.

Mas dada a regra geral 95-5 ( 95% dos ganhos de desempenho vêm do ajuste de 5% do código ), não faz sentido começar com os poderosos recursos dinâmicos e endurecer quando necessário?

Classes Swift que são subclasses de NSObject:

• são as próprias classes Objective-C
• usar objc_msgSend()para chamadas para (a maioria) seus métodos
• fornecem metadados de tempo de execução Objective-C para (a maioria) suas implementações de método

Classes Swift que não são subclasses de NSObject:

• são classes Objective-C, mas implementam apenas alguns métodos para compatibilidade NSObject
• não use objc_msgSend()para chamadas para seus métodos (por padrão)
• não fornecem metadados de tempo de execução Objective-C para suas implementações de método (por padrão)

Subclassificar NSObject em Swift proporciona flexibilidade de tempo de execução Objective-C, mas também desempenho Objective-C. Evitar NSObject pode melhorar o desempenho se você não precisar da flexibilidade de Objective-C.

Editar:

Com o Xcode 6 beta 6, o atributo dinâmico aparece. Isso nos permite instruir o Swift que um método deve usar despacho dinâmico e, portanto, oferecerá suporte à interceptação.

public dynamic func foobar() -> AnyObject {
}

Também descobri que, ao basear uma classe Swift em NSObject, vi alguns comportamentos inesperados em tempo de execução que podem ocultar bugs de codificação. Aqui está um exemplo.

Neste exemplo, onde não baseamos em NSObject, o compilador identifica corretamente o erro em testIncorrect_CompilerShouldSpot, relatando "... 'MyClass' não é conversível para '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
      }
  }
}

Neste exemplo, onde nos baseamos em NSObject , o compilador não detecta o erro em 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
      }
  }
}

Eu acho que a moral é, apenas baseie-se no NSObject onde você realmente precisa!

De acordo com a referência da linguagem, não há requisitos para classes de subclasse de qualquer classe raiz padrão, portanto, você pode incluir ou omitir uma superclasse conforme necessário.

Observe que omitir uma superclasse da declaração da classe não atribui uma superclasse de base implícita de qualquer tipo. Ele define uma classe base, que se tornará efetivamente a raiz de uma hierarquia de classes independente.

Da referência de idioma:

As classes Swift não herdam de uma classe base universal. As classes que você define sem especificar uma superclasse tornam-se automaticamente classes básicas para você construir.

Tentar fazer referência a superpartir de uma classe sem uma superclasse (ou seja, uma classe base) resultará em um erro de tempo de compilação

'super' members cannot be referenced in a root class

Acredito que a grande maioria dos dados do Swift não será objc. Apenas as partes que precisam se comunicar com a infraestrutura Objective C serão marcadas explicitamente como tal.

Até que ponto a introspecção em tempo de execução será adicionada à linguagem, não sei. A interceptação do método provavelmente só será possível se o método permitir explicitamente. Este é o meu palpite, mas apenas os designers de linguagem da Apple realmente sabem para onde estão realmente indo.

O seguinte foi copiado do Swift-eBook da Apple e dá uma resposta apropriada à sua pergunta:

Definindo uma classe-base

Qualquer classe que não herde de outra classe é conhecida como classe base.

As classes Swift não herdam de uma classe base universal. As classes que você define sem especificar uma superclasse tornam-se automaticamente classes básicas para você construir.

Referência

É normal. Veja os objetivos de design do Swift: O objetivo é fazer desaparecer grandes classes de problemas de programação. Swizzling de métodos provavelmente não é uma das coisas que você deseja fazer com o Swift.