objective c - requerimientos - Suprimir "''...'' está en desuso" al usar respondsToSelector

xcode peso

Question

Apoyo 10.4+ al elegir la API más actual en tiempo de ejecución:

if ([fileManager respondsToSelector:@selector(removeItemAtPath:error:)])
[fileManager removeItemAtPath:downloadDir error:NULL];
else
[fileManager removeFileAtPath:downloadDir handler:nil];

En este caso, 10.5 y arriba usarán removeItemAtPath:error: y 10.4 usará removeFileAtPath:handler: Genial, pero sigo recibiendo advertencias del compilador para los métodos anteriores:

warning: ''removeFileAtPath:handler:'' is deprecated [-Wdeprecated-declarations]

¿Hay una sintaxis de if([… respondsToSelector:@selector(…)]){ … } else { … } que insinúa que el compilador (Clang) no advierta en esa línea?

Si no es así, ¿hay alguna forma de etiquetar esa línea para ignorarla para -Wdeprecated-declarations ?

Después de ver algunas de las respuestas, permítanme aclarar que confundir al compilador con no saber lo que estoy haciendo no es una solución válida.

Answer 1

Encontré un ejemplo en el Manual del usuario del compilador Clang que me permite ignorar la advertencia:

if ([fileManager respondsToSelector:@selector(removeItemAtPath:error:)]) {
[fileManager removeItemAtPath:downloadDir error:NULL];
} else {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
[fileManager removeFileAtPath:downloadDir handler:nil];
#pragma clang diagnostic pop
}

Answer 2

No estoy seguro de si clang es lo suficientemente inteligente como para captar esto, pero si no es así, podría intentar usar performSelector:withObject:withObject: o crear e invocar un objeto de invocación NS.

Answer 3

Podría declarar un archivo separado designado para llamar a métodos obsoletos y establecer los indicadores del compilador por archivo en Xcode para ignorar -Wdeprecated-declarations . A continuación, puede definir una función ficticia en ese archivo para llamar a los métodos en desuso y, por lo tanto, evitar las advertencias en sus archivos de origen reales.

Answer 4

Podrías simplemente lanzar fileManager a un id . Los ids pueden referirse a cualquier objeto Objective-C, por lo que no se supone que el compilador verifique los métodos a los que se llama en uno:

[(id)fileManager removeItemAtPath:downloadDir error:NULL];

no debe generar advertencias o errores.

Por supuesto, esto plantea otros problemas, es decir, pierde toda la verificación en tiempo de compilación de los métodos llamados en la id . Por lo tanto, si escribe mal el nombre del método, etc., no se detectará hasta que se ejecute esa línea de código.

Answer 5

Si considera que cualquier forma de "confusión" del compilador es una solución inválida, probablemente tenga que vivir con la advertencia. (En mi libro, si pregunta cómo deshacerse de una advertencia, no es prudente mirar a un caballo de regalo en la boca y decir que algo no es válido simplemente porque no se parece a lo esperado).

Las respuestas que funcionan en tiempo de ejecución implican enmascarar la operación que está sucediendo con el despacho dinámico para que el compilador no se queje de la llamada obsoleta. Si no te gusta ese enfoque, puedes desactivar "Avisar sobre las funciones en desuso" en tu proyecto de Xcode o en la configuración del objetivo, pero en general es una mala idea. Desea saber acerca de las API en desuso, pero en este caso desea usarlo sin previo aviso. Hay formas fáciles y difíciles de hacerlo, y es probable que los considere "inválidos" de alguna forma, pero eso no impide que sean efectivos, incluso correctos. ;-)

Una forma posible de evitar las advertencias pero aún seleccionar en tiempo de ejecución es usar objc_msgSend() directamente:

objc_msgSend(fileManager, @selector(removeFileAtPath:error:), downloadDir, nil];

Esto es lo que el tiempo de ejecución de Objective-C hace bajo las cubiertas de todos modos , y debe lograr el resultado que desee con un mínimo de alboroto. Incluso puede dejar la línea original comentada arriba para mayor claridad. Sé que la documentación dice: "El compilador genera llamadas a la función de mensajería. Nunca debe llamarlo directamente en el código que escribe". Solo tú tienes que decidir cuándo está bien doblar las reglas.