Swift lleva unos cuantos años siendo el lenguaje de programación predilecto de Apple. Desde su aparición en 2014 hemos visto como en cada edición de la WWDC ha ido cobrando más protagonismo, sustituyendo a Objective-C en la mayoría de demos y talleres. Muchas de las grandes deficiencias de este lenguaje se han ido subsanando a lo largo de las distintas iteraciones, hasta llegar a la última versión propuesta, Swift 5.
Esta versión se caracteriza por tener menos cambios en sintaxis y funcionalidad que sus predecesoras, pero cuenta con un gran característica que lleva aquejando a Swift desde sus inicios: la estabilidad de la Application Binary Interface o ABI. ¿Qué es ABI?, pues es una interfaz que permite a los binarios de Swift interactuar con otras librerías y componentes. Básicamente define detalles a muy bajo nivel como las llamadas a funciones, la representación de datos en memoria, donde se encuentran los metadatos o como acceder a ellos.
Actualmente Swift tiene un gran problema, y es que no tiene una ABI estable, esto significa que cada binario compilado (o sea, cada aplicación escrita en Swift), empaqueta su propia versión de la Librería Dinámica de Swift, ya que esta no reside en el propio sistema operativo. Por ello, si una app usa Swift 3.0, contiene la Librería Dinámica con ABI 3.0, mientras que si otra está compilada con Swift 4.2 contiene la Librería Dinámica con ABI 4.2. Por lo tanto si con Swift 5 llegamos a tener una ABI estable, Swift podrá ser integrado en el sistema operativo y su ABI podrá ser compatible con todas las versiones de Swift posteriores a la 5.
Esta mejora supone ciertas ventajas, como que el tamaño de las aplicaciones se reducirá, los cambios en la sintaxis de Swift serán menos drásticos, habrá menos migraciones y se podrán crear Frameworks pre-compilados en Swift. También acarrea ciertas desventajas, como que se limita los cambios en las Interfaces Públicas y los Símbolos, al igual que restringe el crecimiento y la evolución de Swift como estábamos acostumbrados. Aunque esto último, viendo el grado de madurez actual del lenguaje, ya no es tan problemático como en sus inicios.
Por otro lado, se han introducido pequeñas mejoras, como la habilidad de crear “raw strings” mediante el símbolo # entre la cadena de texto. Esto es bastante útil en textos que tienen que escapar comillas o en expresiones regulares. También se han añadido “Dynamically callable types”, que permiten marcar un tipo como directamente invocable, esto permite a Swift funcionar mejor con lenguajes dinámicos como Python y Javascript. Junto a esto, también se ha introducido el atributo @unknown para diferenciar entre los casos por defecto en un switch de un enumerado y los casos no contemplados.
Así que, quitando de lado unas pequeñas mejoras de sintaxis y otras pocas incorporaciones, estas serían las principales novedades de Swift 5, un lenguaje de programación en alza, con sus grandes ventajas pero también con múltiples inconvenientes. La comunidad en torno a este lenguaje no hace más que crecer, teniendo un repositorio muy activo y una página donde poder informarte de todas las mejoras que animo a que consultéis.
Esta versión se caracteriza por tener menos cambios en sintaxis y funcionalidad que sus predecesoras, pero cuenta con un gran característica que lleva aquejando a Swift desde sus inicios: la estabilidad de la Application Binary Interface o ABI. ¿Qué es ABI?, pues es una interfaz que permite a los binarios de Swift interactuar con otras librerías y componentes. Básicamente define detalles a muy bajo nivel como las llamadas a funciones, la representación de datos en memoria, donde se encuentran los metadatos o como acceder a ellos.
Actualmente Swift tiene un gran problema, y es que no tiene una ABI estable, esto significa que cada binario compilado (o sea, cada aplicación escrita en Swift), empaqueta su propia versión de la Librería Dinámica de Swift, ya que esta no reside en el propio sistema operativo. Por ello, si una app usa Swift 3.0, contiene la Librería Dinámica con ABI 3.0, mientras que si otra está compilada con Swift 4.2 contiene la Librería Dinámica con ABI 4.2. Por lo tanto si con Swift 5 llegamos a tener una ABI estable, Swift podrá ser integrado en el sistema operativo y su ABI podrá ser compatible con todas las versiones de Swift posteriores a la 5.
Figura 1: App compilada con Swift 4.2 |
Esta mejora supone ciertas ventajas, como que el tamaño de las aplicaciones se reducirá, los cambios en la sintaxis de Swift serán menos drásticos, habrá menos migraciones y se podrán crear Frameworks pre-compilados en Swift. También acarrea ciertas desventajas, como que se limita los cambios en las Interfaces Públicas y los Símbolos, al igual que restringe el crecimiento y la evolución de Swift como estábamos acostumbrados. Aunque esto último, viendo el grado de madurez actual del lenguaje, ya no es tan problemático como en sus inicios.
Figura 2: Raw Strings y @unknown default |
Por otro lado, se han introducido pequeñas mejoras, como la habilidad de crear “raw strings” mediante el símbolo # entre la cadena de texto. Esto es bastante útil en textos que tienen que escapar comillas o en expresiones regulares. También se han añadido “Dynamically callable types”, que permiten marcar un tipo como directamente invocable, esto permite a Swift funcionar mejor con lenguajes dinámicos como Python y Javascript. Junto a esto, también se ha introducido el atributo @unknown para diferenciar entre los casos por defecto en un switch de un enumerado y los casos no contemplados.
Así que, quitando de lado unas pequeñas mejoras de sintaxis y otras pocas incorporaciones, estas serían las principales novedades de Swift 5, un lenguaje de programación en alza, con sus grandes ventajas pero también con múltiples inconvenientes. La comunidad en torno a este lenguaje no hace más que crecer, teniendo un repositorio muy activo y una página donde poder informarte de todas las mejoras que animo a que consultéis.
No hay comentarios:
Publicar un comentario