NSString: isEqual vs. isEqualToString

94

Qual é a diferença entre isEqual:e isEqualToString:?

Por que as classes estão adicionando métodos isEqualTo * (isEqualToArray para NSArray, isEqualToData para NSData, ...) em vez de apenas substituir isEqual:?

— Jaka Jančar
fonte

103

isEqual:compara uma string com um objeto e retornará NOse o objeto não for uma string. isEqualToString:é mais rápido se você souber que ambos os objetos são strings, como afirma a documentação :

Considerações Especiais

Quando você sabe que ambos os objetos são strings, esse método é uma maneira mais rápida de verificar a igualdade do que isEqual:.

isEqualTo<Class>é usado para fornecer verificações específicas de igualdade. Por exemplo; isEqualToArray:verifica se os arrays contêm um número igual de objetos e se os objetos em um determinado índice retornam YESpara o isEqual:teste.

— Abizern
fonte

3

Se você acredita em Aaron Hillegass, então não há diferença de desempenho, apenas um pouco de segurança do tipo: blog.bignerdranch.com/334-isequal-vs-isequaltostring

— Caro

2

Obrigado pelo link - útil. Embora você esteja nos pedindo para acreditar em Mark Dalrymple - quem eu acredito :)

— Abizern

Link atualizado: bignerdranch.com/blog/isequal-vs-isequaltostring

— Máx.

16

Além disso, para escrever seus próprios métodos -isEqual:e -isEqualTo<Class>:, a convenção é permitir argumentos nulos para -isEqual:e levantar uma exceção para argumentos nulos para-isEqualTo<Class>:

— Jonathan Dann
fonte

1

Eu não tinha encontrado isso antes, alguma documentação que você conheça?

— Mike Abdullah

2

Isso não parece ser verdade para isEqualToString, que apenas retorna NÃO se você passar nil.

— Jaka Jančar

9

Interessante, está documentado na seção Comparação de objetos do <a href=" developer.apple.com/documentation/Cocoa/Conceptual/… Guia de fundamentos</a>

— Jonathan Dann

Isso não é verdade. isEqualToString não levanta uma exceção.

— respectTheCode

1

A página da web do Cocoa Fundamentals Guide diz: "Este documento pode não representar as melhores práticas para o desenvolvimento atual." É velho, aparentemente.

— cbh2000

5

Meu palpite é que ele fornece um pequeno aprimoramento de desempenho, já que isEqualToString: não terá que verificar o que foi passado.

— iKenndac
fonte

Seu palpite provavelmente é verdade :)

— Philip007

5

Expandindo as respostas @Abizern e @Jonathan Dann, isEquale isEqualToStringtrabalhar com nilvalores.

- (void)testStringEqual {
    NSString *string = nil;

    STAssertFalse([string isEqual:@"test"], @"NSString isEqual");
    STAssertFalse([string isEqualToString:@"test"], @"NSString isEqualToString");

    // Note that these both return NO
    STAssertFalse([string isEqual:nil], @"NSString isEqual");
    STAssertFalse([string isEqualToString:nil], @"NSString isEqualToString");

    string = @"test";

    STAssertTrue([string isEqual:@"test"], @"NSString isEqual");
    STAssertTrue([string isEqualToString:@"test"], @"NSString isEqualToString");

    STAssertFalse([string isEqual:nil], @"NSString isEqual");
    STAssertFalse([string isEqualToString:nil], @"NSString isEqualToString");
}

— respectTheCode
fonte

4

Eu recomendo altamente isso . Os benefícios de desempenho de isEqualToString são basicamente insignificantes para a maioria dos aplicativos. Mas existem duas outras distinções que o autor menciona:

Segurança de tipo
A forma como nilé tratada

— Ben Packard
fonte

Não vejo nenhuma diferença na maneira como o nil é tratado pelos dois. Seja nulo, seja o receptor, o argumento ou ambos.

— SayeedHussain

O que quer que seja "isso" não existe mais: /

— Jared Grubb

1

Obrigado @JaredGrubb, encontrei o novo URL.

— Ben Packard