AnyObject e Any em Swift


91

Eu não entendo quando usar AnyObject e quando usar Any em Swift.

No meu caso, tenho um dicionário

[Corda: ???]

??? : Pode ser Int, Double, Float, String, Array, Dictionary

Alguém pode me explicar a diferença entre Any e AnyObject e qual usar no meu caso.

Alak

Respostas:


114

AnyObjecté apenas para tipos de referência (classes), Anyé para tipos de valor e de referência.

Então você deve ir [String: Any].

Casting de tipo para Any e AnyObject

O Swift oferece dois tipos especiais para trabalhar com tipos não específicos:

  • Any pode representar uma instância de qualquer tipo, incluindo tipos de função.
  • AnyObject pode representar uma instância de qualquer tipo de classe.

NOTA:

Use Anye AnyObjectsomente quando precisar explicitamente do comportamento e dos recursos que eles fornecem. É sempre melhor ser específico sobre os tipos com os quais você espera trabalhar em seu código.

Da linguagem de programação Swift : https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/TypeCasting.html#//apple_ref/doc/uid/TP40014097-CH22-ID342

-

Observe também que quando você trabalha com a API Cocoa, é comum receber um Array de AnyObject, isso ocorre porque os arrays Objective-C NÃO são tipificados. Portanto, você precisa convertê-los para o tipo de array que você espera.

-

EDITAR: (22 de dezembro de 2015)
Na última declaração, observe que isso está mudando com Swift 2.0 e Xcode 7. A
Apple introduziu genéricos 'leves' em Objective-C, portanto, muitas APIs de cacau agora já retornam o tipo correto.

EDITAR: (18 de outubro de 2016)
Observe que, a partir do Swift 3.0, Objective-C ids agora são importados como Any, não mais como AnyObject.


18
Observe que String, Arraye Dictionarynão são classes, para esses use Qualquer.
zaph

6
Nem Int, Double e Float são.
Teejay

11
Sim, mas isso geralmente é óbvio. Não é tão óbvio que NSString, NSArraye NSDictionarysão classes, as versões do Swift funcionalmente semelhantes não são classes e isso confunde muitos desenvolvedores.
zaph

1
Qualquer um também representa opcionais? Ou deve ser expresso como Qualquer?

1
@robdashnash Any não representa opcionais. ? deve ser adicionado para torná-lo opcional
cripta

46

Se você usa Anyou AnyObjectdepende do uso pretendido:

Se o seu dicionário será usado apenas no código Swift, então você deve usar Anyporque seus tipos ( Int, Double, Float, String, Array, e Dictionary) não são objetos.

Se você for passar seu dicionário para rotinas Objective-C que esperam um NSDictionary, então você deve usar AnyObject.

Quando você import Foundationou import UIKitou import Cocoa, é possível declarar a matriz como [String: AnyObject], mas neste caso Swift está tratando o seu Int, Double, Floatliterais como NSNumber, seus Strings como NSString, seus Arrays como NSArray, e seus dicionários como NSDictionary, todos os quais são objetos. Um dicionário usando AnyObjectcomo tipo de valor é conversível em NSDictionary, mas um usando Anynão é.


1

De acordo com a documentação do Swift da Apple,

  • Qualquer um pode representar uma instância de qualquer tipo, incluindo tipos de função e tipos opcionais.
  • AnyObject pode representar uma instância de qualquer tipo de classe.

Para obter mais detalhes, consulte: Blog


1

Verifique esta resposta SO :

Os genéricos são seguros para o tipo, ou seja, se você passar uma string como genérica e tentar usar como um inteiro, o compilador reclamará e você não poderá compilar o seu (o que é bom). (Isso acontece porque o Swift está usando a tipagem estática e pode fornecer um erro do compilador). Se você usar AnyObject, o compilador não tem ideia se este objeto pode ser tratado como uma String ou como um Integer e basicamente permitirá que você faça o que quiser com ele (o que é ruim) como se você tentasse usar um objeto que foi passado como String quando é um inteiro, o aplicativo irá travar. (Isso acontece porque o Swift está usando tipagem dinâmica e só fornecerá um erro de tempo de execução)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.