Fermer le menu

La stabilité, principal enjeu de Swift 4

Nicolas Furno | | 20:30 |  75

Swift est le langage de programmation d’avenir pour Apple. L’entreprise espère remplacer à terme Objective-C par ce nouveau venu né en interne et qui dépasse désormais le cadre strict de Cupertino en étant un langage open source que n’importe qui peut exploiter.

Craig Federighi sur la scène de la WWDC 2015, en train d’annoncer le passage en open source de Swift. Cliquer pour agrandir

Parti de zéro, ce langage a beaucoup évolué depuis sa première apparition publique, il y a près de trois ans. Apple avait prévenu dès le départ que c’était un projet en cours et à chaque mise à jour annuelle, Swift a évolué de manière significative. Ses concepteurs ont ajouté des fonctions importantes et surtout modifié des fonctions existantes, obligeant les développeurs à modifier leurs apps. Voire, dans certains cas, à repartir de zéro.

Le nouvel enjeu pour Swift est désormais la stabilité. Elle était déjà évoquée pour la troisième version sortie l’an dernier, mais le passage en open source a obligé Apple à revoir ses priorités. Swift 4 devrait être présenté à l’occasion de la WWDC de juin et la stabilité fait partie de ses objectifs.

Qu’est-ce que la stabilité pour Swift ? On fait le point !

La stabilité du code source est en bonne voie

Pour atteindre une stabilité identique à celle d’Objective-C, Swift doit d’abord garantir aux développeurs que leur code source restera compatible d’une version à l’autre. Pour y parvenir, c’est assez simple sur le papier : la syntaxe ne doit pas changer, pas plus que les noms des différentes fonctions indispensables.

Voici à quoi ressemblent quelques lignes de code en Swift. Cliquer pour agrandir

C’est simple en théorie, mais en pratique c’est une autre affaire pour un langage aussi jeune que l’est Swift. S’engager sur la stabilité du code dès le départ aurait contraint Apple à bloquer son nouveau langage dans son état initial. Ce qui n’aurait pas été une bonne idée : quand les développeurs du monde entier ont commencé à l’utiliser sur leurs projets, de nombreux problèmes ont été révélés.

Les premières mises à jour de Swift ont largement modifié le langage et sa syntaxe. Certaines fonctions ont été revues entièrement parce qu’elles ne convenaient pas à l’usage, d’autres ont été ajoutées. Ce travail a été permis précisément parce qu’Apple a choisi dès le départ de ne pas stabiliser le code source. Les développeurs qui ont utilisé Swift 1 savaient que leur travail ne serait pas compatible avec Swift 2, et pareil avec Swift 3.

Apple a tout fait pour simplifier le processus à chaque mise à jour. L'environnement de développement Xcode intégrait à chaque mise à jour majeure des algorithmes capables de convertir automatiquement le code source. C’est du temps gagné pour les développeurs, mais ces fonctions automatiques ne peuvent pas tout faire et les changements sont souvent trop importants pour qu’un travail manuel ne soit pas nécessaire derrière.

Xcode 8 est capable de convertir des lignes de code Swift 2 en Swift 3. Ce processus automatique permet de gagner du temps, mais il ne fonctionne pas à tous les coups.

Pour offrir une stabilité du code source, Swift doit garantir à tous les développeurs que le code qu’ils écrivent aujourd'hui sera encore parfaitement compatible dans le futur. Cela ne veut pas dire que le langage ne pourra plus évoluer, mais les évolutions devront ajouter des éléments et non en retirer. Et en cas de modification d’un élément déjà présent, il faudra s’assurer que les changements ne cassent pas la syntaxe déjà existante.

Pour faciliter les futurs ajouts et changements du langage, Swift 3.1 a amélioré l'attribut @available(). Il permet désormais à un développeur de conserver une partie de son code, même s’il n’est plus valide. Le compilateur chargé de transformer les lignes de code en un programme exécutable pourra gérer ces lignes en théorie incompatibles en utilisant une ancienne version de Swift. Cet ajout permettra à Apple d’avancer à un rythme soutenu sans casser pour autant la stabilité du code source pour ses développeurs.

La stabilité ABI, un enjeu important et complexe

La stabilité du code source est pratiquement assurée pour Swift 4. Néanmoins, ce n’est que la première étape et le langage devra encore assurer une stabilité ABI, ce qui est encore plus difficile. Déjà prévue pour Swift 3, elle pourrait être retardée encore un petit peu, pour de bonnes raisons.

Pour commencer, il n’est pas inutile d’expliquer rapidement ce qu’est une ABI (Application Binary Interface). Cette interface binaire-programme est une brique de bas niveau qui s’intercale en général entre les applications et le système d’exploitation. C’est elle qui fait le lien entre le programme créé par le développeur et le langage machine, c'est-à-dire la suite de bits qui sera exécutée par le processeur.

Hopper, un logiciel pour macOS qui permet de décortiquer un programme en affichant son code assembleur. Cliquer pour agrandir

macOS et iOS sont livrés avec les ABI indispensables à Objective-C. Un programme codé dans ce langage peut ainsi être exécuté uniquement après compilation de son code source. En revanche, les ABI nécessaires à Swift ne sont pas encore intégrées dans les systèmes d’Apple. Pour qu’une app codée avec ce langage fonctionne, elle doit ainsi être accompagnée de ses propres ABI qui feront le lien avec le processeur.

Très concrètement, toutes les apps codées en Swift intègrent une série de fichiers, des bibliothèques dynamiques (extension .dylib) qui font office d’ABI. C’est le cas sur iOS comme sur macOS et tant que la stabilité ABI ne sera pas atteinte, ce sera toujours le cas.

Toutes les applications en Swift doivent intégrer plusieurs fichiers qui contiennent les interfaces indispensables entre le programme et le processeur. Cliquer pour agrandir

Cette approche a deux inconvénients. Le premier, plutôt mineur, est qu’elle alourdit le poids des applications elle-même. Le fichier total est plus lourd de 10 à 20 Mo en moyenne quand une application exploite Swift par rapport à une autre qui n’est codée qu’avec Objective-C. C’est un problème en soi, mais pour une part croissante des apps disponibles, c’est un surpoids assez marginal.

L’autre inconvénient est plus gênant. Puisqu’une app intègre ses propres ABI, elle reste en partie figée dans le temps et ne bénéficie pas d’évolutions potentielles de la plateforme. Si Apple améliore les ABI dédiées à Objective-C, par exemple pour améliorer la gestion de la mémoire, toutes les apps développées avec ce langage en bénéficieront. Si l’entreprise fait la même chose pour Swift, les applications devront être mises à jour pour bénéficier des changements.

La stabilité ABI est un enjeu également essentiel, mais l’atteindre est plus difficile et prendra peut-être davantage de temps que la stabilité du code source. Il faut dire qu’une fois décrétée, elle limite les possibilités d’évolution en devant s’assurer que les ABI restent compatibles avec toutes les applications existantes. En cas d’incompatibilité, toutes les applications sorties après la stabilisation et sans ABI intégrée pourraient être bloquées.

Apple doit s’assurer que les ABI sont complètes et suffisamment mûres pour les stabiliser. Pour cela, il reste encore du travail, notamment sur l’utilisation de la mémoire, un point qui est géré directement par ces interfaces. Chris Lattner, le créateur de Swift qui dirigeait l’équipe en charge du langage avant son départ pour Tesla, explique dans une interview qu’il y a tant de travail que cet objectif ne sera peut-être pas atteint pour Swift 4.

Il ajoute que ce n’est pas forcément la tâche la plus importante pour Swift à court terme. La priorité serait plutôt d’améliorer le compilateur et notamment sa fiabilité et sa rapidité, en particulier sur les plus gros projets. Les messages renvoyés lors d’une erreur doivent aussi être plus clairs, ajoute Chris Lattner qui considère donc que ce devrait être la priorité, avant la stabilisation des ABI.

Précisons que ce n’est plus lui qui dirige le projet au sein d’Apple. Néanmoins, il semble que Ted Kremenek, son successeur, soit sur la même longueur d’ondes.

Pour conclure

Que la stabilité ABI accompagne la stabilité du code source avec Swift 4 ou qu’elle soit reportée à une future version, il n’en reste pas moins que c’est désormais l’un des plus gros enjeux du langage. C’est une étape indispensable avant sa diffusion plus large et notamment son utilisation dans les systèmes d’exploitation d'Apple.

Craig Federighi sur la scène de la WWDC 2014, lors de la première présentation publique de Swift. Cliquer pour agrandir

Dans la même interview, Chris Lattner expliquait d’ailleurs que la stabilité ABI était un prérequis pour que les développeurs de frameworks adoptent Swift. Plus que la syntaxe de base d’un langage, ce sont eux qui sont primordiaux, puisqu’ils permettent aux développeurs de créer leurs applications. Les frameworks servent notamment à accéder au matériel, par exemple pour prendre une photo directement dans une app.

Les développeurs peuvent déjà créer des apps complètes et complexes en Swift. Mais pour qu’Apple utilise plus largement son propre langage en interne, la stabilité est la prochaine étape cruciale.

Catégories: 
Tags : 

Les derniers dossiers

Ailleurs sur le Web


75 Commentaires Signaler un abus dans les commentaires

avatar Eaglelouk 02/02/2017 - 20:40 via iGeneration pour iOS

Bien joué les forced unwrap dans votre code 🌚c'est vachement safe dites moi

avatar LaurentH macG 02/02/2017 - 21:18

Busted! 😳

avatar Ded77 02/02/2017 - 23:40 via iGeneration pour iOS

@Eaglelouk

Ça manque clairement de "guard" ^^



avatar BeePotato 03/02/2017 - 14:32

@ Ded77 : « Ça manque clairement de "guard" ^^ »

Même remarque qu’à Eaglelouk : si on sait qu’il ne peut pas y avoir de nil, il est stupide de mettre un guard.

Tester quelque chose qui ne doit pas se produire, à quoi cela servirait-il ?
D’autant que si le cas nil ne doit normalement pas se présenter, ça signifie qu’on ne sait pas pourquoi il se présenterait un jour — et donc que, si jamais il se présente tout de même, on ne saura pas comment réagir. Que devrait faire le else de ce fameux guard ?
Juste se débrouiller pour faire continuer la vie de l’application comme si de rien n’était, sans s’émouvoir de s’être retrouvé dans une configuration totalement anormale ? Ou quitter brutalement l’application parce que cette situation est bien trop anormale ?
Dans le cadre d’une application qui a des données cruciales à sauvegarder, cette seconde approche peut avoir un intérêt (mais c’est assez joueur, puisqu’on ne peut pas être sûr de la qualité de ce qui sera enregistré). Mais pour application comme celle de MacG, c’est inutile et laisser le plantage se produire est bien suffisant.

Le guard, ce n’est pas un outil magique qui sauve de tous les problèmes.

avatar LaurentH macG 03/02/2017 - 19:31 (edité)

@BeePotato

"Tester quelque chose qui ne doit pas se produire, à quoi cela servirait-il ?"

C'est utile lors du développement.

Personnellement, je préfère un bon vieux "assert" qui génère un nop dans le build de production. En gros je me sert (de temps en temps) des force unwrap comme des assert. Avec les guard on ne fait que passer la patate chaude (a moins d'utiliser fatalError)

Mais bon je suis peut être de l'ancienne école...

avatar BeePotato 04/02/2017 - 11:36

@ LaurentH : « C'est utile lors du développement. »

Oui, lors du développement, de même que tous les autres tests qu’on peut développer avec les outils de test qui sont là pour nous aider dans cette tâche.
Mais ça ne sert qu’au moment du développement, pour y détecter les erreurs. D’où l’usage, comme tu l’as dit, d’un assert (ou de n’importe quel truc équivalent et viré lors de la compilation finale).

Mais ce que proposaient les autres, c’était d’avoir des tests s’exécutant aussi en permanence dans la version distribuée de l’application. Des tests ne servant strictement à rien, puisqu’on ne saurait pas quoi faire dans le cas où ils échoueraient.

avatar fte 03/02/2017 - 09:22 via iGeneration pour iOS

@Eaglelouk

L'article parle de stabilité de Swift, pas des applications codées en Swift :p

Ce qui pique vraiment les yeux ici c'est les variables d'instance marquées d'un point d'exclamation.

avatar BeePotato 03/02/2017 - 14:34

@ fte : « Ce qui pique vraiment les yeux ici c'est les variables d'instance marquées d'un point d’exclamation. »

Il y a pourtant des cas où ça se justifie parfaitement.

Juger un bout de code sans son contexte, c’est souvent osé.

avatar BeePotato 03/02/2017 - 14:22

@ Eaglelouk : « Bien joué les forced unwrap dans votre code 🌚c'est vachement safe dites moi »

Si le développeur sait que ça ne peut pas avoir la valeur nil à cet endroit du code, oui, c’est parfaitement « safe ».

avatar fte 03/02/2017 - 14:33 via iGeneration pour iOS

@BeePotato

Les champs!, moyen.

avatar BeePotato 03/02/2017 - 14:42 (edité)

@ fte : « Les champs!, moyen. »

Non.
On ne dispose pas ici d’assez d’éléments pour juger si l’usage qui en est fait est « moyen » (c’est-à-dire mauvais) ou s’il est tout à fait normal, raisonnable et propre.

Si ce concept d’implicitly unwrapped optionals (je n’ai jamais réfléchi à comment traduire ça correctement en français) existe dans ce langage, c’est bien parce qu’il y en a des usages parfaitement valides. La documentation d’Apple en présente.

avatar fte 03/02/2017 - 14:59 via iGeneration pour iOS

@BeePotato

Je ne jugeais pas le code dans son ensemble, je soulignais un point qui est dans plus de 90% des cas un usage non pertinent car les cas pertinents sont très rares.

De plus nous sommes en présence d'une WebView et d'un pointeur sur un article. Si tu n'as pas assez d'information avec ces quelques éléments pour déterminer si un implicitely unwrapped optional est pertinent, c'est certainement que tu n'as pas assez d'expérience avec Swift ou avec les WebViews ou les deux. 99% de chance que ce soit une facilité prise pour contourner l'initialisation de l'instance sans se coltiner des optionals dans le reste du code. Ils seraient déclarés fileprivate ou private encore, soit, mais ils sont internal.

J'ai largement assez d'éléments pour dire qu'il s'agit d'une utilisation inappropriée.

avatar BeePotato 03/02/2017 - 15:20

@ fte : « Je ne jugeais pas le code dans son ensemble »

En effet. Ce n’est d’ailleurs pas ce que j’ai prétendu. J’ai juste rappelé que tu ne disposais pas de suffisamment de contexte pour juger les deux lignes de code auxquelles tu faisais référence.

« je soulignais un point qui est dans plus de 90% des cas un usage non pertinent »

Ben dis donc, ça ne doit pas être marrant de passer ses journée à lire l’intégralité du code écrit en Swift sur toute la planète ! :-)
À moins que ce « 90 % » ne soit juste sorti au hasard…

« c'est certainement que tu n'as pas assez d'expérience avec Swift ou avec les WebViews ou les deux. »

Non non, ce n’est pas ça. :-)

« J'ai largement assez d'éléments pour dire qu'il s'agit d'une utilisation inappropriée. »

Ah ben oui, suis-je bête : puisque tu lis tous les jours l’intégralité du code Swift produit partout dans le monde afin d’établir tes statistiques, tu en sait forcément bien plus sur le reste du code de cette application que ce que cette petite capture d’écran nous apprend à nous autres, pauvres mortels. Comment n’y ai-je pas pensé plus tôt ? Désolé d’avoir douté de ton omniscience. :-) ;-)

avatar fte 03/02/2017 - 15:40 via iGeneration pour iOS (edité)

@BeePotato

Ça n'a rien à voir avec l'omniscience et je pense que tu le sais parfaitement au vu de certaines de tes autres contributions.

On est en présence d'une pattern et bonne pratique de Cocoa, non limitée aux WebViews par ailleurs, et je me permet de douter très fortement que l'auteur de ce code ait pondu un truc super mega exotique dans ce type de contexte.

Si c'est fait comme c'est généralement fait, c'est clairement un mauvais usage des IUO.

Si c'est super exotique, c'est toute l'implementation qui est un mauvais usage. Le super exotique n'a pas sa place dans un contrôleur sans commentaire aucun (on voit quelques lignes de header très simple, pas de description de comportement de classe exotique). Soit la documentation est en bas dans le fichier soit ailleurs, et dans ce cas c'est la doc qui est à revoir parce qu'on ne fait pas une implémentation exotique en le mentionnant dans un endroit exotique, à moins d'être un développeur exotique. Les développeurs exotiques travaillent seuls et ils ont un vrai job à coté. (second degré caché dans ce paragraphe.)

La programmation c'est super chiant, avec toutes ces bonnes pratiques mortelles et sans originalité...

avatar BeePotato 04/02/2017 - 12:22 (edité)

@ fte : « Ça n'a rien à voir avec l'omniscience et je pense que tu le sais parfaitement au vu de certaines de tes autres contributions. »

D’où, sans doute, la redondance de smileys à la suite de mon commentaire. ;-)
N’empêche, ce n’est pas de l’omniscience, mais le coup des 90% ressemble à un truc sorti tout droit d’un chapeau magique, et le reste semble être juste le résultat d’un gros a priori au sujet de l’usage qui devrait être fait des UIO.

Les UIO, ça n’est pas le mal et ça peut être utilisé bien plus largement que semblent le croire certains.
Ça sert à rappeler au compilateur que le développeur a plus de cartes en main que lui pour savoir comment va se passer la vie d’un bout de code de son application. Ça indique au compilateur que, bien que telle ou telle propriété ne reçoive pas de valeur au moment de l’initialisation de l’instance, le fonctionnement du programme garantit qu’elle aura été initialisée avant son premier accès en lecture et qu’il n’y a donc pas besoin d’encombrer tout le reste du programme de tests inutiles. Chose que le compilateur ne peut pas savoir, mais que le développeur doit savoir.

Et en bonus, les UIO offrent au développeur un fonctionnement qu’on n’avait pas en Objective-C : s’il s’est planté quelque part et qu’il se produit un cas où cette propriété n’a pas été initialisée avant d’être utilisée, on lui garantit un crash immédiat, à l’endroit où elle est utilisée, lui permettant de trouver beaucoup plus facilement son bug.

C’est une bonne fonctionnalité, qui est faite pour être utilisée (à condition, comme toujours, de bien comprendre à quoi elle sert et comment l’utiliser correctement).

avatar fte 04/02/2017 - 14:45 via iGeneration pour iOS

@BeePotato

Cette fonctionnalité existe, pour de bonnes raisons, et il est légitime de l'utiliser avec de bonnes raisons. Je ne disais pas qu'elle devait être supprimée.

Je parlais d'un cas très spécifique, des champs exposés dans un contrôleur d'une WebView.

Je suis dev, je dois utiliser ce contrôleur. Je vois des champs accessibles avec un !. Qu'en penser ? Il n'y a pas de documentation qui me dit si ces champs peuvent ou non être null, si l'encapsulation de l'initialisation garanti qu'ils ne sont jamais null, si une instance de ce contrôleur peut être dans un état invalide et comment le déterminer... En conséquence de quoi je traiterais cette classe comme dangereuse et je considérerais ces champs! comme des champs? et supposerait qu'une valeur null est possible. Et qu'aucune déréference sans vérification ne doit être faite. C'est un contrôleur donc la question du multi threading ne se pose pas vraiment, mais si je devais lire l'un de ces champs! depuis une queue GCD je devrais prendre encore plus de pincettes pour que mon code soit safe.

S'ils sont garantis non null, c'est une mauvaise pratique que d'exposer des champs! ou des champs?.

S'ils ne sont pas garantis d'être null, c'est une mauvaise pratique que d'exposer des champs! plutôt que des champs? car le compilateur ne criera pas si tu oublies ce !.

Après, je suis très curieux d'un exemple où cette pattern a un sens qui justifie pleinement son emploi (dangereux). Si possible dans le cadre d'un contrôleur Cocoa. J'en vois plusieurs dans d'autres cadres...

avatar BeePotato 04/02/2017 - 18:49

@ fte : « Je ne disais pas qu'elle devait être supprimée. »

En effet. Tu disais juste qu’il faudrait ne l’utiliser que de la manière (apparemment très stricte) dont toi tu l’abordes. :-)

« Je suis dev, je dois utiliser ce contrôleur. »

Ben non. Tu ne dois pas.
C’est une classe interne à une application. Pas une classe publique d’un framework destiné à d’autres développeurs.
Et c’est une petite application, pas un monstre développé par une équipe tellement grande que chaque classe doit être pensée comme si elle faisait partie d’un framework public.

Comme je l’ai dit, il faut juger un bout de code dans son contexte. Pas hors contexte.

« Il n'y a pas de documentation qui me dit si ces champs peuvent ou non être null, si l'encapsulation de l'initialisation garanti qu'ils ne sont jamais null, si une instance de ce contrôleur peut être dans un état invalide et comment le déterminer... »

Tu n’en sais strictement rien. Cette documentation existe peut-être bel et bien — juste pas à l’endroit (commentaires dans le code) où tu voudrais manifestement qu’elle soit. Mais tu sais, il n’y a absolument rien de choquant à proposer une documentation séparée. Personnellement, je trouve même ça bien mieux : je passe bien plus de temps à consulter la documentation en ligne de Cocoa qu’à fourrer mon nez dans les commentaires des fichier en-tête du framework. ;-)

Et même sans documentation, ce code te dit quelque chose : il dit que ces champs ne peuvent pas être nuls au moment où tu vas normalement y accéder. C’est le principe même des IUO, c’est donc ce qu’annonce un IUO. Ça répond déjà à bien des questions. Et s’il s’avère ensuite que ce fonctionnement n’est pas respecté, il s’agit alors d’un bug et non d’un défaut de documentation.

« En conséquence de quoi je traiterais cette classe comme dangereuse et je considérerais ces champs! comme des champs? »

Ben non, ce sont des champ!, pas la peine de les traiter autrement.
Si on commence à vouloir utiliser des classes de façons différente de ce qu’elle annoncent clairement comme mode d’utilisation, on arrive vite à un grand n’importe quoi.

« S'ils sont garantis non null, c'est une mauvaise pratique que d'exposer des champs! »

Non, c’est le principe même d’un IUO (mais tu semble avoir du mal avec cette idée).

« ou des champs?. »

Là, ce serait une erreur, puisque ce type de propriété annonce clairement la possibilité d’un nil.

avatar fte 04/02/2017 - 21:23 via iGeneration pour iOS

@BeePotato

Bah. Libre à toi d'en penser ce qui te chante.

Les patterns existent pour de bonnes raisons. On peut les utiliser pour le bien comme pour le mal. Et par chance il m'incombe de décider des bonnes pratiques et conventions à suivre dans mon job.

Swift n'a pas inventé les optionals soit dit en passant, explicites ou non. Ce sont de vieilles connaissances. Est-ce qu'ils remontent aux premières itérations de la théorie des types (191x), ou à Church (193x), je ne sais pas. Mais c'est vieux.

Je note que tu ne m'as donné aucun cas où un champ optional implicite public - donc déréférençable sans validation et conduisant à un crash si null - était justifié et préférable à un optional explicite. Prove me wrong. ;)

avatar LaurentH macG 03/02/2017 - 20:24

@BeePotato

Yep, moi je *veux* que mon programme crash dès qu'il y a un truc d'anormal.

si

let app = UIApplication.shared.delegate! as! AppDelegate

crash, ça m'intéresse *beaucoup* de savoir pourquoi, plutôt que d'appeler

app?.window?.rootViewController?.present( ...)

qui se traduit par "fait ça, ou cas où ça marche..."

avatar BeePotato 04/02/2017 - 11:41

@ LaurentH : « Yep, moi je *veux* que mon programme crash dès qu'il y a un truc d’anormal. »

Ouaip. Le crash immédiat face à ce genre de problème, c’est un plaisir pour débugger — et c’est bien plus « safe » (pour reprendre le terme de ceux qui voulaient mettre des guard partout) que d’essayer de faire survivre une application qui est manifestement dans un état totalement imprévu où on ne peut donc plus garantir un fonctionnement normal et la moindre sécurité des données.

« plutôt que d'appeler
app?.window?.rootViewController?.present( ...)
qui se traduit par "fait ça, ou cas où ça marche..." »

Tout à fait, surtout quand on poursuit par : « et au cas où ça ne marche pas ? Euh… ben… euh… » :-)

avatar Lonesome Boy 02/02/2017 - 20:46 via iGeneration pour iOS

À moitié hors sujet: quelle est l'alternative au si puissant KVC/KVO d'Objective-C en Swift? Comment "observer" un attribut qui n'appartient pas à une de mes classes en Swift, sans avoir recours à un objet ou un protocole Obj-C?
Le mécanisme de KVO me semble si pratique (bien que n'étant pas développeur Obj-C moi même), surtout quand on bosse sur d'autres la gage et qu'on se dit que cela simplifierait grandement la vie si un mécanisme équivalent était dispo, je suis curieux de savoir quel est l'équivalent ou l'alternative en Swift.

KVO me semble important pour les développements Cocoa, je suis étonné qu'il ne soit pas dispo en Swift. Mais peut-être que ma petite expérience Obj C est maintenant trop ancienne et que depuis un autre mécanisme a remplacé KVO?

avatar Eaglelouk 02/02/2017 - 20:56 via iGeneration pour iOS

@Lonesome Boy

KVO est loin d'être important. Il vaut mieux l'éviter au maximum. Si tu as vraiment besoin d'observer des attributs d'un objet, tu fais un protocol et tu gères une liste d'observers.

avatar RedMak 03/02/2017 - 01:21 via iGeneration pour iOS

@Eaglelouk

KVO est treees important, oui il peut être dangereux mais bien utilisé c'est just un regale !
Et just pour info, xcode lui meme utilisé ÉNORMÉMENT le kvo ;)

Et pour swift, là je suis entrain de convertir une app de swift 2.3 à swift 3, en bref, c pas une galère mais c pas facile facile, en plus xcode fait des erreur dans la conversion, par example j avait un bou de code qui test : si une fonction existe dans l'SDK d'ios 8.3 est ultérieur on l'utilise sinon on utilise une autre, et bien xcode a laissé le test (le bloc if available) mais a remplacé les 2 fonctions par celle de 8.3 et donc si l'app est ouverte dans un iPhone/iPad ayant ios 8.2 ou inférieur et bien ... l'app crash .. alors faites attention.

swift c'est bien mais pour l'instant j'aime plus objC car plus riche, plus stable et car j'aime bien les pointeurs moi :p

avatar JegnuX 03/02/2017 - 14:47

Oui KVC/KVO est énormément utilisé dans plein d'endroit. Cora Data, les bindings, les NSPredicate, et plein d'autres tachons reposent sur KVC et/ou KVO. Et évidemment de nombreuses applications reposent dessus.

Mais Eaglelouk a raison, son utilisation est loin d'être safe et bien que pratique, il faut trouver de nouveaux moyens pour faire la même chose. Et Swift a plein de features qui permettent d'accomplir la même chose, mais Safe (via protocols, generics, etc...).

L'avantage c'est que ça rend explicite dans le code quelles property sont observable ou non. Là où aujourd'hui tu dois fouiller dans la doc (par exemple, UIKit n'est pas 100% compliant avec KVO)

Enfin, KVO est un mécanisme ancien, mais aujourd'hui de nouveaux patterns ont émergé. Je pense notamment au Functional Reactive Programming (avec RxSwift par exemple) qui remplace KVO de façon très avantageuse. Bon après c'est réducteur de parler de RxSwift en "meilleur KVO", car c'est bien bien plus que ça.

avatar BeePotato 03/02/2017 - 15:07 (edité)

@ JegnuX :
Il y a depuis toujours de quoi remplacer le KVC/KVO. Mais c’est tellement plus lourd à utiliser…
Il faut bien avouer que c’est cet aspect qui nous fait aimer le KVC/KVO (tant qu’on ne tombe pas sur un problème ;-) ).

Pages