Swift 5.9 et ses macros sont finalisés pour les développeurs
Apple n’a pas seulement distribué une mise à jour d’iOS et de tous les systèmes associés, les développeurs ont aussi droit à une nouveauté pour leur quotidien cette semaine. Une mise à jour de Swift, le langage de développement conçu par Apple, a en effet été finalisée et la version 5.9 est désormais celle qui est stable. Cette mise à jour ajoute de nombreux éléments, à la fois au niveau du langage lui-même que des outils qui l’entourent.
L’une des nouveautés est l’ajout des macros, qui servent à définir du code qui sera utilisé à plusieurs reprises dans un programme. Cela peut être aussi simple que la définition de paramètre pour du texte (ci-dessous) ou nettement plus complexe, avec des macros qui peuvent être définies par un autre programme. Les concepteurs de Swift présentent notamment cette nouveauté comme une manière de simplifier l’utilisation de fonctionnalités complexes pour des bibliothèques de code.
Nous avions évoqué plusieurs autres nouveautés pour Swift 5.9 ainsi que le gestionnaire de paquets Swift au printemps :
Le futur de Swift se dessine à la veille de la WWDC23
Cette mise à jour améliore aussi l’expérience des développeurs en Swift sous Windows, le langage n’étant pas limité à l’écosystème d’Apple. Le langage de développement est intégré avec Xcode 15, il est aussi proposé pour Windows et Linux à cette adresse.
Zut ! J’vais m’allonger dans le PlayGround 🛝 et pousser des cris d’oiseaux Swift Swift à mon iPeud où le Python va les croquer.
Dans ma boite notre "directeur technique" est à priori contre les macros comme en C. Mais il adore Swift. Curieux de voir ce qu'il va en penser...
@ marc_os : Il reste des raisons d’être contre les macros en Swift, mais moins de raisons qu’en C.
@ BeePotato
J'aurais dû m'y attendre à ce genre de réponse.
C'est comme leurs explications bidons sur le pourquoi du non support du terme protected an plus de private et public dans les classes. Soit disant que parce qu'en théorie la protection pouvait être contournée en Obj-C, alors ils n'ont pas inclus le support de ce mot clé dans le langage. Mais si on lit l'argumentaire en entier (faudrait que je le recherche, mais j'ai fait cette recherche chez moi et je n'ai pas le lien ici au taf), et bien on s'aperçoit que la vraie raison de ce non support ce sont des limitations de Swift lui même...
De toute façon, ces gens n'aiment pas la programmation orientée objet. (Et j'ai mon avis sur la raison de ce désamour). Le pire, c'est que du coup leur implémentation de la POO est "inefficace"; de leur aveu même ils recommandent d'utiliser des structs plutôt que des classes pour des raisons de performance*.
Bref.
Je sais, on est obligé de faire avec.
Comme on dit, il faut faire contre mauvaise fortune bon cœur.
(*) C'est comme pour les services publics : "On" les rend inefficaces, on les sabote quasiment, après on peut dire que les services publics sont mauvais et qu'il faut donc privatiser.
@ marc_os : « J'aurais dû m'y attendre à ce genre de réponse. »
Peut-être parce que tu connaissais déjà la réponse. 😉
« C'est comme leurs explications bidons »
Sympa, la comparaison, merci ! 😛
Il n’y avait pourtant rien de bidon dans ma réponse (qui était certes très concise, mais pas moins vraie pour autant).
« De toute façon, ces gens n'aiment pas la programmation orientée objet. (Et j'ai mon avis sur la raison de ce désamour). »
Par curiosité (et non pour troller ensuite, promis), j’aimerais bien connaître cet avis.
@ BeePotato
> « De toute façon, ces gens n'aiment pas la programmation orientée objet. (Et j'ai mon avis sur la raison de ce désamour). »
> Par curiosité (et non pour troller ensuite, promis), j’aimerais bien connaître cet avis.
Les trois quarts des développeurs que j'ai croisés ont du mal avec la POO et ne l'utilisent que pour de l'encapsulation dirais-je, avec des classes singleton qui sont des "manager" de ceci ou cela. Du procédural structuré dirais-je. En Swift désormais ils ne jurent que par les structs. Par contre, des enums bien velus qui regroupent des choux et des carottes grâce aux données associées à chaque case, ils adorent.
Quand j'ai vu certains "refactoring" orienté objet de certains collègues supposés suivre les principe de la POO, j'ai eu parfois quelques surprises. Car tous les concepts ne correspondent pas à des choses physiques comme les cours de POO aiment les utiliser. Exemple: les êtres vivants qu'on peut organiser en arbre bien hiérarchique où on peut définir une classe pour chaque nœud, les classes en bas de l'arbre étant des "filles" des classes au dessus.
- Êtres vivants
- pantes
- champignons
- animaux
- mammifères
...
Quand on a des concepts abstraits, c'est une autre paire de manche.
Perso, en plus de l'architecture construite "à priori" en amont, j'utilise beaucoup la POO comme moyen de factorisation. Si deux classes (sans parent en Obj-C) doivent exécuter du code commun, je mets ce code dans une classe parente. La relation sera alors d'ordre "technique".
C'est aussi comme pour les pointeurs. "Ça fait peur".
Du coup ils sont rassurés que Swift soit comme VisualBasic de ce point de vue.
@ marc_os : « Le pire, c'est que du coup leur implémentation de la POO est "inefficace"; de leur aveu même ils recommandent d'utiliser des structs plutôt que des classes pour des raisons de performance*. »
J’ai oublié deux remarques au sujet de ce passage :
• Cette recommandation n’indique pas forcément une inefficacité. Le fait qu’il y ait des optimisations possibles avec les structs qui ne le sont pas avec les classes ne signifie pas forcément que l’implémentation des classes de Swift est moins efficace qu’en Objective C, par exemple.
• Avec des structs (au sens swiftien du terme), on fait aussi de la POO — ce n’est pas parce que le terme « classe » n’apparaît pas qu’il n’y a plus d’objets. C’est d’ailleurs un point que j’ai toujours détesté en Swift : ce choix des termes struct et class, qui, je trouve, n’indiquent absolument pas la différence sémantique qu’il y a entre ces deux modèles (quel rapport ces termes ont avec le concept de référence/valeur ?). Je ne sais pas quels termes seraient plus adaptés, mais pour avoir déjà dû les expliquer à des débutants, je sais que ceux-là ne le sont pas.
@ BeePotato
> Cette recommandation n’indique pas forcément une inefficacité
Faudrait faire des mesures de perfs...
> Avec des structs (au sens swiftien du terme), on fait aussi de la POO
De la POO sans héritage ? 😳
C'est un nouveau concept.
Non, les structs, c'est de l'encapsulation.
Remarque : Pour palier à l'absence d'héritage et à la factorisation du code que permet l'héritage dont je parlais plus haut, j'ai des collègues qui définissent des protocoles.
Sauf que les protocoles en Swift, c'est plus que les protocoles en Obj-C :
Ils peuvent contenir du code !
Du coup, c'est ce qu'ils font : Ils mettent du code commun dans des protocoles, et les structs qui en ont besoin "répondent" au protocole.
Cette pratique - permise par Swift - dénature AMHA totalement le concept de "protocole" qui était un engagement à implémenter des fonctions.
En Swift, ce n'est plus le cas.
Car du code "par défaut" peut être implémenté dans les protocoles. Du coup, les protocoles ne sont plus des engagements, des obligations pour une struct/classe à implémenter telle ou telle fonction.
La clarté du code en prend aussi un sacré coup - mais c'est un autre sujet.
Un point que je trouve regrettable dans Swift, mais c'est inhérent au langage et à la manière dont il a été implémenté, c'est que ce langage n'est pas compatible avec toutes les versions de macOS, iOS, etc, contrairement aux langages "traditionnels", comme C, C++ ou Objective-C où seul l'usage des API du système était limitant.
Quand on développe en Swift , alors on ne peut pas produire de logiciel pour les anciens OS, même si on n'utilise que des API système compatibles.
Pour Swift 5.9, les versions supportées sont :
iiOS 13, macOS 10.15, tvOS 13, ou watchOS 6
Les clients avec de "veilles machines" sont donc exclus.
Quand on développe en Swift on fait donc de l'obsolescence programmée si on veut bénéficier de la toute dernière version du langage.
Si on veut supporter macOS 10.12 par exemple, on est bloqué à Xcode 13 (et la version de Swift que Xcode 13 supporte). Donc ces belles nouveautés du langage, et bien on ne peut pas en profiter.
Exception : Jusqu'à ce jour, à ma connaissance la dernière version de tvOS est supportée par toutes les ATV qui tournent sous tvOS. (Même s'il peut y avoir des limitations comme celle concernant FaceTime, ce qui n'introduit pas un problème de langage en soit, c'est plutôt une limitation comparable à celle que peuvent poser les API qui éventuellement ne sont disponibles que sous certaines conditions.)
@marc_os
J’ai été très étonné aussi de ce genre de chose. Car il avait promis une compatibilité ABI. Et pourtant, on ne peut pas utiliser un xcframework compilé en Swift 5.8 avec la 5.9 par exemple.
Et c’était pour moi plus simple lorsque Swift était en dehors du système. Car cela permettait de mettre à jour Swift sans devoir se contenter de la version système.
En tout cas, il aurait dû prévoir un moyen de mettre à jour les bibliothèques du langage Swift en dehors du Système même lorsqu’il est inclus.