Es difícil decir qué piensa hacer Apple aquí. KVO en Objective-C depende de las características dinámicas del lenguaje que Swift no admite para mejorar la seguridad y la velocidad. Un equivalente de Swift tendría que ser (al menos parcialmente) una característica del lenguaje, no una extensión de la clase base como lo es KVO.
(Dato curioso: el compilador Objective-C no sabe absolutamente nada acerca de KVO. KVO es solo un grupo de objetos que utilizan varias características de tiempo de ejecución de Objective-C, con algunos métodos en una categoría NSObject. No hace nada que no puedas hacer hazlo una vez que importes .)
También hay una cuestión de si el equipo Swift querrá apoyar a KVO. Permitir que un observador sea observado tiene un costo de tiempo de ejecución. Objective-C KVO utiliza características dinámicas para garantizar que solo se penalicen las instancias y propiedades que realmente se están observando, pero nuevamente, esa no es una opción en Swift. Eso puede llevar al equipo de Swift a favorecer un régimen donde las propiedades deben marcarse explícitamente como observables. Esto no sería del todo malo (Objective-C KVO a menudo pierde los cambios cuando una clase no espera que observe una propiedad en particular), pero sería un gran cambio de Objective-C.
- ¿Es mejor construir una aplicación de iOS con Appcelerator u Objective C?
- ¿Cuáles son algunas buenas herramientas de comentarios que se pueden usar en la aplicación móvil para capturar comentarios de clientes / usuarios una vez que la aplicación ha sido publicada?
- ¿Cuándo, si alguna vez, no deberías incluir la barra de estado en una aplicación de iPhone?
- Pregunta que contiene suposiciones: ¿Por qué iOS 9 es tan lento en comparación con versiones anteriores de iOS?
- ¿Cuánto costaría convertir un sitio web de WordPress en una aplicación (Android e iOS)?
