Home » Noticias » Swift, se perfila la gran transformación de su API (se cambiará la especificación de Cocoa)
Swift API Changes

Swift, se perfila la gran transformación de su API (se cambiará la especificación de Cocoa)

Si habéis trabajado con Swift y con Cocoa, seguro que os habéis dado cuenta que el lenguaje aun tiene (por compatibilidad) una gran herencia de Objective-C. Como ya hemos comentado muchas veces, mientras Objective-C es mucho más gramatical, Swift es más concreto, aunque siempre tenemos que enfrentarnos a casos que reiteran en exceso el significado de una llamada a un método y sus parámetros (por poner un ejemplo).

Swift está atado, de por sí, a fallos en su definición gramatical y la propia especificación usada con Cocoa, que no permite sacar provecho de la mayor flexibilidad de este frente a Objective-C. Sobre este problema ha hablado recientemente Dave Abrahams (líder de desarrollo de la librería estándar de Swift y responsable de la mejor charla de la pasada WWDC sobre Programación Orientada a Protocolos) en el blog oficial de Swift.

Él mismo, en la evolución natural que tiene el lenguaje, se ha dado cuenta de la enorme diferencia en la calidad y claridad del código cuando una librería o implementación se realiza nativamente en Swift sin contar con elementos de Cocoa o derivados. Y por esto, los responsables del lenguaje se han planteado dar el siguiente paso: transformar toda la API de Swift para sacar el mayor provecho de las facultades del lenguaje y marcar distancia “con el pasado”.

Como ejemplo que ilustra el cambio al que se quiere llegar, sobre estas líneas se presenta un fallo gramatical en la forma de invocar a métodos de una clase. Siendo path un objeto de tipo UIBezierPath que pertenece a la librería UIKit, sus métodos son los que son porque ya se trabajaba así en Objective-C y la API de Swift usa la misma especificación para asegurar compatibilidad. Pero esto no debería ser así, porque estamos usando elementos de otro lenguaje con otra estructura dentro de Swift y estamos haciendo que este no sea todo lo eficiente que podría ser.

La solución sería evitar lo reiterativo de esta llamada que invoca a addLineToPoint cuando el parámetro es ya un punto CGPoint. Por lo tanto el toPoint sobraría porque ya va implícito que será a un punto. De igual forma, fillWithBlendMode tampoco sería correcto porque el parámetro que recibe es un modo de blend, ergo, estamos repitiendo. Y lo idóneo es que usemos, igualmente, el polimorfismo para construir la especificación en función del tipo de parámetro enviado. Así, un método sabrá qué tiene que hacer o no: conocerá qué versión de sí mismo ha de invocar.

Cocoa se “Swiftifica”

El gran problema es que Cocoa reside aun en objetos de Objective-C y las guías de desarrollo están supeditadas a lo que era este, sin aprovechar grandes ventajas de Swift. Pero para que Cocoa y Swift convergan correctamente, hay que separar a Cocoa creando una capa de especificación más propia de Swift y no usar la misma que se usa en Objetive-C que es otro lenguaje con otras reglas y mucho más gramatical. La forma en que Swift trabaja con los valores por defecto y cómo organiza el orden de parámetros de una función, es un ejemplo de una función de alto nivel que no puede ser usada porque Objective-C lo hace de otra manera y donde podemos ver la situación de desventaja que vive Swift.

El ejemplo que hemos puesto, del artículo de Abrahams, ilustra a la perfección el tipo de cambio que Apple persigue y para el que, al ser el lenguaje de código abierto, se va a contar con toda la comunidad de desarrolladores. El propósito es cambiar toda la especificación del lenguaje para aprovechar las ventajas estructurales de Swift, sus nuevas características como la orientación a protocolos y mucho más, separando Cocoa de Objective-C de Cocoa de Swift (aunque no se pierda la compatibilidad).

Ya es hora que Swift tenga “personalidad” propia y no dependa todo lo que depende a día de hoy de Objective-C. Apple ha creado para ello tres pasos que harán públicos de esta transformación, donde se podrá colaborar y que a su vez se irá informando de cada paso dado. Antes este proceso era cerrado, pero ahora la evolución del lenguaje como código abierto es plenamente pública y participativa.

  • Cambios en cómo Cocoa es importado.
  • Cambios en la superficie de la librería estándar
  • Guías de diseño de APIs

Con esto se persiguen cambios conceptuales y de especificación como el siguiente:

En esta llamada invocamos a addArcWithCenter y enviamos como primer parámetro origin. Pero si exploramos la posibilidad de transformación, tendría un código más limpio que definiría qué hará el método en función de sus parámetros y no en función del nombre. La idea es aprovechar Swift para que los nombres de los métodos o funciones sean concretos a su funcionalidad genérica y que sean los parámetros quienes dicten su comportamiento específico.

En este caso, hemos reducido el nombre a addArc para luego incorporar un parámetro externo que obliga a poner el nombre del primer parámetro, siendo este centery dejando claro cuál es el propósito contextual de invocar a addArc.

Iremos informando de los cambios que se vayan produciendo, pues se ha fijado el 5 de febrero como fecha para cerrar la etapa de proposiciones sobre el lenguaje y cerrar estos cambios que comenzarían a implementarse en la librería estándar de Swift.

Pero ojo, no tenemos que temer por nuestros programas. Primero porque no estamos hablando de cambios en el lenguaje: se trata de la especificación de Cocoa y otras librerías: cambiar los nombres de métodos, parámetros y propiedades, para aprovechar el potencial de Swift en su forma de construir APIs. Además, estos cambios en las llamadas y la “Swiftificación” de estas APIs, implican cambios de especificación 1 a 1 (lo que antes se hacía así, ahora se hace de esta otra forma) que con un asistente de migración como el que ya existe en Xcode, nos permitiría cambiar nuestro código sin apenas esfuerzo ya que la equivalencia es clara entre especificaciones.

Lo importante, es aprender cómo será el cambio y cambiar la forma en que nos enfrentamos a Swift como lenguaje y en relación al resto de elementos del mismo. Tocará revisar nuestros conocimientos, así que preparaos y Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Portada Vídeo News

Apple Coding News llega a YouTube

Los boletines de noticias de Apple Coding llegan a YouTube. Descúbrelos y disfruta la mejor forma de seguirnos y estar al día. La más completa. Una forma única de no solo oír las noticias del mundo del desarrollo como nadie más te las cuenta, también podrás descubrir todos los detalles detrás con el apoyo visual del formato que solo YouTube permite. Una nueva experiencia Apple Coding.