La stabilité, principal enjeu de Swift 4

Nicolas Furno |

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.

avatar Eaglelouk (non vérifié) | 

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

avatar LaurentH | 

Busted! ?

avatar Ded77 | 

@Eaglelouk

Ça manque clairement de "guard" ^^

avatar BeePotato | 

@ 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 | 

@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 | 

@ 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 | 

@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 | 

@ 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 | 

@ 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 | 

@BeePotato

Les champs!, moyen.

avatar BeePotato | 

@ 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 | 

@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 | 

@ 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 | 

@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 | 

@ 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 | 

@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 | 

@ 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 | 

@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 | 

@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 | 

@ 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 | 

À 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 (non vérifié) | 

@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 | 

@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 | 

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 | 

@ 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 ;-) ).

avatar fte | 

@BeePotato

Le Reactive Programming est un candidat pour remplacer KVO.

Fondamentalement c'est très similaire, mais le typage change. On passe d'API faiblement typée et de typage dynamique à des API fortement typées et généralement statiquement typées (aka vérifié à la compilation).

Signals signals signals, et composition ! Ça va beaucoup plus loin que KVO en réalité mais bref.

avatar BeePotato | 

@ fte : « Le Reactive Programming est un candidat pour remplacer KVO.
Fondamentalement c'est très similaire, mais le typage change. On passe d'API faiblement typée et de typage dynamique à des API fortement typées et généralement statiquement typées (aka vérifié à la compilation). »

Et du coup, ça devient plus lourd à utiliser.

« Signals signals signals, et composition ! Ça va beaucoup plus loin que KVO en réalité mais bref. »

Mouais. Ça n’introduit rien de bien nouveau non plus, hein.

avatar fte | 

@BeePotato

Plus lourd ? Pas vraiment. C'est typé et le compilateur vérifie plus de choses. C'est plus lourd parce qu'il y a des types, mais tout le poids de la vérification est transféré au compilateur, donc c'est plus léger.

Rien de nouveau ? La composition de signaux et l'historique d'iceux ouvre des portes assez intéressantes malgré tout.

avatar C1rc3@0rc | 

On remarque qu'il y a une tres grosse incoherence avec Swift chez Apple.

Swift a ete promu pour securiser le developpement.
L'idée affiché est d'avoir un langage qui evite les erreurs de programmations classiques et soit capable d'eviter au mieux les erreurs qu'elles soient de realisation mais aussi de conception, cela autant chez de developpeur experimenté que chez le novice.

Pour ce faire Swift se repose sur des approches complexes et puissantes, dont le typage dynamique et l'inference de type qui viennent du modele fonctionnel.
Il y a aussi toute la partie gestion de la memoire qui la aussi a opté pour le principe des langages fonctionnels.

Tout cela est tres bien, mais c'est mettre la charrue avant les bestiaux qui la tire!

Si on veut que le codeur ne fasse pas d'erreur de realisation, faut que la syntaxe et la grammaire soient logiques, simples, sans ambiguité et stables.

Si on veut que le developpeur ne fasse pas d'erreur de conception, il faut que la structure du langage soit coherente avec un modele determiné et que le choix de realisation s'adapte au modele conceptuel et pas l'inverse.

Les idées affichées derriere le choix de Swift sont les memes que celles qui ont ete a la base de Python, ADA et Eiffel. Ces langages datent, meme s'ils sont toujours aussi pertinents et adaptés. Donc on a aujourd'hui le recul et l'experience pour savoir comment atteindre ce type d'objectif.

Deja pourquoi avoir opté pour un tout nouveau langage, la ou Python ou Eiffel etaient de bons candidats? Le syndrome du «pas inventé ici»?

Le probleme c'est que tout semble indiquer que Swift a ete conçu et realisé sans aucune consideration de ces expériences et fondamentaux.
Le principe de base qui consiste a reflechir et structurer le cadre de realisation semble ne jamais avoir existé. Au contraire, on plus l'impression que la genese du langage repose sur la realisation de besoins ponctuels et divers, un peu comme le sont les langages "glue" comme ceux des shell (bash) ou des bidouillage infâmes comme PHP.

Il semble qu'a aucun moment l'idee de la syntaxe ait ete arrété sur un ensemble de regles coherentes, et que la selection/elimination/rajout se soit faite sur la pression communautaire, donc tardivement.
Un exemple c'est la syntaxe de la boucle "for" a la C qui a heureusement fini par etre evacuée.

Cela va plus loin encore puisque les principe de nommages sont ambigus et inconstants, et cela va jusque dans l'API. Certes l’héritage de Smalltalk dans Cocoa est tres fort, mais il n'est pas en soit incompatible avec une structuration stable et logique, Smalltalk etant lui meme tres logique.
C'est un peu comme si entre Smalltalk, C et AppleScript il n'avait pas ete fait de choix et que la decision revient a la communauté... C'est contraire aux principes et objectifs affichés

Quand a l'inconsistence de l'ABI, c'est pitoyable, surtout qu'on est sur une VM et pas sur un compilateur natif.

Bref Switf a du potentiel, mais va falloir compter sur d'autre qu'Apple pour en faire une reussite! Et aujourd'hui on est sur une version 0.3 et certainement pas 3...

avatar Domsware | 

@C1rc3@0rc

Il me semble que tu oublies l'un des objectifs de Swift : la transition depuis Objective-C. Il fallait partir de l'existant pour notamment assurer une transition en douceur. Tout en récupérant un maximum de l'écosystème existant. Ainsi Swift se mixe avec Objective-C et s'utilise avec Xcode.

Les choix de nommage peuvent laisser perplexes néanmoins ce n'est que du nommage. Les fondations elles-mêmes sont solides et ne varient que peu.

Dès la première version j'ai ressenti une grosse influence du langage Ada et consorts. Et cela ne fait que s'affirmer d'une version à l'autre.

avatar C1rc3@0rc | 

«Il me semble que tu oublies l'un des objectifs de Swift : la transition depuis Objective-C. »
Nullement.
On a vu qu'Apple intégrait Python et Ruby dans Xcode pour exploiter directement Cocoa et il n'y avait pas de souci par rapport a Objective-C.
De plus Swift ne repose pas sur Objective-C, et au contraire s'en distingue dans ses "valeurs". L'idée derriere Objective-C etait justement l'inverse de celle de C++ qui visait a rendre C plus "safe" tout en y rajoutant le paradigme objet. Objective-C lui comptait sur la vitesse et le modele dynamique de Smaltallk, cela construit sur un preprocesseur permettant de garder la pleine compatibilité de C, et cela aussi a l'inverse de C++.

L'idée de Swift c'est pas la transition depuis Objective-C, au contraire, c'est de permettre a quasi n'importe qui de pouvoir programmer dans un mixage de paradigmes tout en limitant les erreurs de codage. C'est un tabula rasa rationnel, sauf qu'entre les intentions et la mise en oeuvre, on dirait qu'il y a des marches qui ont ete ratées!

D'ailleurs pourquoi partir sur un nouveau nieme langage et pas se baser sur ceux qui repondent aux criteres de base.

Autre point assez aberrant, mais qui peut s'expliquer, c'est l'absence de gestion intrinsèque du parallélisme. D'autant que cette notion existe dans ADA et que l'autre Swift (qui existait avant la version d'Apple) lui est massivement orienté parallèle

Autre element perturbant, pourquoi Swift n'integre pas intrinsequement des type dataset, comme dans R ou Python avec Numpy, alors qu'on voit que ce type est de plus en plus incontournable des qu'on sort de la programmation systeme et construction d'interface.

Pour un langage d'avenir y a quand meme des manques massifs sur l'avenir du developpement.

«Dès la première version j'ai ressenti une grosse influence du langage Ada et consorts. Et cela ne fait que s'affirmer d'une version à l'autre.»

Et d'ou vient cette impression?

avatar fte | 

@C1rc3@0rc

Swift n'est pas un langage dynamiquement typé.
Le typage dynamique n'est pas du tout une caractéristique des langages fonctionnels.
L'inférence de types n'est pas non plus une caractéristique des langages fonctionnels, c'est une facilité liée aux compilateurs évolués.
La gestion de mémoire n'est pas non plus celle des langages fonctionnels. Elle est hybride au mieux et il manque une claire définition de monads, IO en particulier, pour que le modèle mémoire soit vraiment celui des langages fonctionnels "académiques".
Tu parles de Python. Quel Python ? Il y en a plusieurs déclinaisons incompatibles...
Dire que Swift a été désigné sans considération pour les fondamentaux est non seulement faux mais insultant.
Swift ne compile pas pour une VM.
Il n'y a pas de pression de la communauté, il y a un processus de consultation en place, très intéressant et productif.

avatar C1rc3@0rc | 

Le probleme de Swift c'est que c'est pas le langage d'un paradigme mais qu'il mange a un peu tous les râteliers.
Bien sur qu'il y a du typage dynamique et le typage inféré pour la compilation vient des travaux sur les compilateurs Lisp et langage fonctionnels en general. Regarde du cote de CaML .

Pourquoi donner la responsabilité du typage au compilateur ou a l'interpreteur dans les langages a typage statiques. La seule chose que le compilateur a a faire c'est verifier qu'il n'y a pas de violation de type et que les transmutations sont explicites. L'idée de donner la responsabilité du typage au compilateur n'a pas de raison d'etre dans les langages a typage statiques, par definition.

Apres faut faire une grosse difference entre le typage dans les langages de haut niveau qui offre un socle logique et le typage dans les langages de bas niveau qui n'est la que pour permettre des optimisations manuelles et de verification pour le compilateur.

La gestion automatique de la memoire vient en droite ligne de Lisp et a toujours ete une caracteristique des langages de haut niveau. Apres les modeles de realisation varient que ce soit le garbage collector ou le reference counting et ils ont evolué dans le temps en fonction des architectures et de l'efficacité des algo. L'approche hybride est un compromis qui permet de resoudre des problemes de performance et de lag notamment en embarqué.

«Tu parles de Python. Quel Python ? Il y en a plusieurs déclinaisons incompatibles...»
Y a qu'un Python dont 2 iterations co-evoluent 2.x et 3.x et la sortie de la version 3 a pris 8 ans!
D'autres langages empruntant la syntaxe de python existent, mais ce n'est pas Python, et ils s'annoncent comme tels.

«Dire que Swift a été désigné sans considération pour les fondamentaux est non seulement faux mais insultant.»
Moais, et la boucle for du C qui a ete expurgé en v3, t'appelles ca comment toi?

«Swift ne compile pas pour une VM.»
Donc Swift sort du code objet ARM ou x86 nativement?

«Il n'y a pas de pression de la communauté, il y a un processus de consultation en place, très intéressant et productif.»
C'est pas le sentiment que donne la lecture des forums...

Perso face au processus de developpement de Swift j'ai plus le sentiment d'etre face a Javascript (et encore lui a une normalisation) que ADA.

avatar fte | 

@C1rc3@0rc

C'est un tel charabia, c'est trop tard pour m'en soucier.

Juste deux points.

1) oui, Swift est compilé vers du natif. Éventuellement les phases assemblage et linkage sont laissées au soin de l'AppStore.

2) ML est un langage fortement et statiquement typé, avec inférence de types.

avatar fte | 

@C1rc3@0rc

Oh. Il n'existe pratiquement aucun langage mono paradigme aujourd'hui. BTW.

avatar BeePotato | 

@ C1rc3@0rc : « L'idée de donner la responsabilité du typage au compilateur n'a pas de raison d'etre dans les langages a typage statiques, par definition. »

Tu sembles ne pas comprendre à quoi sert l’inférence de type. Il ne s’agit nullement de « donner au compilateur la responsabilité du typage ». Il s’agit d’avoir un compilateur suffisamment moderne pour admettre qu’à tel endroit du code, le type d’une expression est connu facilement sans aucune ambiguïté, et que donc le développeur n’a pas besoin de le taper juste pour faire plaisir à un stupide compilateur. Rien de plus.

« Moais, et la boucle for du C qui a ete expurgé en v3, t'appelles ca comment toi? »

Moi, j’appelle ça une erreur, parce que cette syntaxe de boucle est bien pratique.
Mais une erreur minime, vu que les boucles se réécrivent très bien autrement.

« Donc Swift sort du code objet ARM ou x86 nativement? »

Swift, non (après tout, ce n’est qu’un langage). Mais un compilateur Swift, oui. ;-)

« Perso face au processus de developpement de Swift j'ai plus le sentiment d'etre face a Javascript (et encore lui a une normalisation) que ADA. »

Ah ben oui, clairement, ce n’est pas le même processus de création que pour ADA. Et alors ?
Bien d’autres langages ont été créés selon un processus différent de celui utilisé pour ADA, et ça ne nous empêche pas de les utiliser joyeusement.

avatar C1rc3@0rc | 

«Tu sembles ne pas comprendre à quoi sert l’inférence de type.»

A travers ta reponse, j'ai l'impression que tu ne comprends pas ce qu'est un type et a quoi sert le typage.

Je vais pas revenir dessus, mais le typage offre 2 fonctions: construire et verifier une logique et permettre une optimisation du code machine.

L’inférence de type (1958) vient a la base des langages fonctionnels et de leur besoin d'etre efficaces sans pour autant devoir descendre a un bas niveau, ce qui casserait la logique de raisonnement par rapport au modele. L'inference permet donc bien d'attribuer un type et de l'adapter a la logique et a la cible.
L'inference de type dans les langages de plus bas niveau et particulièrement procéduraux vient de la nécessité de simplifier l’écriture (moins y a a ecrire, moins y a de risque de faute de frappe - enfin tant qu'on garde une syntaxe et une grammaire coherente, pas comme en C...) tout en conservant la sécurité. Son intérêt est plus discutable, mais elle permet aussi de compenser des erreurs de design du langage, et comme de toute façon les bases de l'inference sont presentes pour verifier le code et l'optimiser, autant l'utiliser.

"l'intelligence" du compilateur vient de l'intelligence du langage (et son niveau d'abstraction) et de la capacité a faire des optimisations poussées pour une architecture cible.

Ensuite quand dans un langage on a une fonction de détermination du type qui peut s'utiliser avec un controle ( genre un switch type(of: var_toto) ) on est pas sur un langage a typage statique, mais au moins en partie dynamique. Et ça veut dire qu'a un moment il y a une faille dans la structure logique et que la verification sera partielle.

Quant au probleme de la boucle C c'est qu'elle viole allégrement toutes les regles de securité en permettant une assignation dans un test et pire encore une declaration dans un test. C'est une connerie du meme niveau que le goto.

«Ah ben oui, clairement, ce n’est pas le même processus de création que pour ADA. Et alors ?»
Et alors? Cela est contradictoire avec les intentions affichées qui devraient être les piliers du langage.

Finalement, si le cap est mis sur la stabilité pour la v4 c'est bien qu'il y a un très gros probleme d'instabilité et d'inconsistance.
Aujourd'hui il est déraisonnable de se lancer sur un gros projet en Swift. Le developpement en Swift est valable pour des petits soft qui prennent quelques semaines d'ecriture au plus et qui n'auront pas a evoluer. C'est quand meme un probleme pour un langage qui proclame qu'il met l'accent sur la securisé et la fiabilité!

avatar BeePotato | 

@ C1rc3@0rc : « Pour ce faire Swift se repose sur des approches complexes et puissantes, dont le typage dynamique et l'inference de type »

Il est amusant de lire que Swift se repose sur le typage dynamique alors que la plus grosse différence qui frappe quand on arrive d’Objective-C est justement que Swift est complètement orienté vers un typage statique (ce qui était un de ses objectifs de départ). :-)
Il y a quelques possibilités de typage dynamique pour pouvoir coopérer avec Objective-C, mais c’est accessoire.

« qui viennent du modele fonctionnel. »

Comment ça ?

« Il y a aussi toute la partie gestion de la memoire qui la aussi a opté pour le principe des langages fonctionnels. »

??
La gestion de la mémoire reprend directement le modèle de Cocoa, qu’on utilisaiat déjà en Objective-C.

« Deja pourquoi avoir opté pour un tout nouveau langage, la ou Python ou Eiffel etaient de bons candidats? Le syndrome du «pas inventé ici»? »

Plutôt le syndrome du « pas parfaitement adaptés à la tâche », associé au syndrome du « essayons de créer un langage taillé sur mesure pour la tâche pour laquelle on veut l’utiliser, en reprenant les meilleurs idées vues ailleurs ».

« Cela va plus loin encore puisque les principe de nommages sont ambigus et inconstants, et cela va jusque dans l’API. »

N’oublions pas que l’API des bibliothèques de base n’est pas arrivée toute seule. Pour la plus grosse part, elle était déjà là depuis longtemps, avec son historique et un fort besoin de conserver une bonne compatibilité avec l’existant.

« Quand a l'inconsistence de l'ABI, c'est pitoyable »

Ben non, c’est normal pour un truc tout neuf et pas encore finalisé.
Certains reprochent régulièrement à Apple de développer certaines choses dans son coin, en secret, et de ne révéler leur existence que quand il est trop tard pour en influencer l’évolution.
Avec Swift, c’est pour une fois l’approche opposée qui a été retenue : en parler très tôt, bien avant que ce soit finalisé, et consulter plein d’extérieurs à Apple pour décider (en partie) de l’orientation du développement. Et on trouve tout de même des gens pour râler. :-)

« surtout qu'on est sur une VM et pas sur un compilateur natif. »

Non non, pas de VM.

« Bref Switf a du potentiel, mais va falloir compter sur d'autre qu'Apple pour en faire une reussite! »

Ah, voilà ! Tu ne pouvais pas commencer par présenter la conclusion à laquelle tu voulais arriver ? Ça t’aurait évité d’avoir à écrire tout le reste pour tenter de la justifier. :-P

avatar fte | 

@BeePotato

Il y a beaucoup de confusion sur ce que sont (classique) les typages statique / dynamique / fort / faible.

Il y a aussi confusion entre l'immutabilité élevée au niveau du modèle de gestion de mémoire (des valeurs, pas de places, monad IO), et le copy-on-write limité et local de Swift (beaucoup de places partout, aucun protocol d'accès enforcé, fort peu de valeurs, des vraies).

Il y a aussi la croyance que les autres langages ne sont pas passés par des étapes et des transitions comme Swift l'a fait.

Et très certainement une confusion entre le bitcode produit pour l'AppStore, et un bytecode comme Java ou C# et leurs machines virtuelles.

avatar BeePotato | 

@ fte : « Il y a aussi la croyance que les autres langages ne sont pas passés par des étapes et des transitions comme Swift l'a fait. »

Oui, ça c’est quelque chose qu’on voit de manière étonnamment fréquente, je trouve. À lire certains avis sur l’évolution de Swift, on a un peu l’impression que le C++11 existait dès 1983. :-)

avatar fte | 

@BeePotato

J'ai une explication à ça. Ce n'est pas étonnant en fait.

Les gens ont la vision courte, ils ne voient que la surface des choses et ils raisonnent sur des impressions. Circé l'a très bien résumé d'ailleurs, il disait "j'ai plus le sentiment de" un peu plus haut.

Les croyances sont plus importantes que les faits.

Dès lors on nous balance que Swift compile pour une VM, que son problème est d'être multi-paradigmes (alors que tous les langages le sont ou presque) ou encore que son design était pourri et que la pression de la communauté à forcé Apple a apporter des changements majeurs (boucle for en exemple, hum).

Les impressions et croyances avant les faits. C'est la nouvelle méthode "d'analyse". Et c'est ce qui donne des posts comme plus haut auquel je répondais en soulignant au moins 10 absurdités...

On est tous coupable de ça à divers degrés bien entendu. Les flux d'information sont si importants aujourd'hui et nous sommes sans cesse noyés dans tant d'informations biaisées qu'il est très difficile de les filtrer et ignorer. Ça nous influence malgré nous, et contre nous. Et ce n'est pas toujours facile de faire la part des choses...

Une solide culture générale et une vision d'ensemble des principaux domaines qui nous intéressent sont essentielles pour trier le bullshit des faits.

avatar C1rc3@0rc | 

Ton interpretation va a l'encontre totale de ce que j'ecris.

Lorsque j'ecris "j'ai le sentiment" c'est pour signifier que je n'ai justement pas la connaissance explicite de la façon de travailler et du cadre qui a ete celui de la genese de Swift. Je ne me place donc pas dans un systeme de croyance!

En tant qu'observateur, la politique et le processus de developpement de Swift est (a ete) une boite noire.
Par contre je peux observer le resultat et l'evolution de ce resultat ainsi que le comportement de l'environnement.
Ce resultat observable s'apparente a celui de Javascript et nullement a celui de ADA.

Ce resultat est incohérent par rapport aux objectifs et principes proclamés.

Un faits issu de cette observation c'est la disparition tardive d'un controle dangereux venant du C. La presence de ce controle est une violation du principe de base (securité) qui prouve une faille dans le developpement.
Le probleme ayant ete reparé tardivement, suivant la publication, il est donc clair que pour un probleme aussi grave c'est la pression de la communauté qui en est a la base.
En plus cela est étayé par les commentaires que j'ai pu lire sur le site...

Apres, je suis d'accord que les notions de typage fort/faible, statique/dynamique, explicite/infere, mutabilité, transtipage, classe/type paramétré,... introduisent beaucoup de confusion surtout quand on les applique hors de leur cadre d'origine et de ce qui les a necessité... 2 notions viennent en plus compliquer: compilateur JIT et VM de differents niveaux

avatar C1rc3@0rc | 

@BeePotato

Regarde du coté de CaML pour ce qui des de la mecanique de typage et la gestion de la memoire.
Certes c'est pas CaML qui a inventé cette gestion par inference et les idées comme le latebinding remontent loin (on retrouve les principes dans les compilateurs Lisp).

Que la gestion de la memoire de Cocoa soit ce qu'elle soit et qu'elle ait d'ailleurs evoluée necessitant une evolution d'Objetive-C c'est une chose. Mais soit Apple fait un langage "glue" pour Cocoa et se le garde, soit Apple fait un langage universel et le detache de Cocoa, parce que Cocoa jusqu'a preuve du contraire ça peut pas exister sur autre chose que MacOS/iOS.
On a le meme bourbier que C# autrement.

«N’oublions pas que l’API des bibliothèques de base n’est pas arrivée toute seule. Pour la plus grosse part, elle était déjà là depuis longtemps, avec son historique et un fort besoin de conserver une bonne compatibilité avec l’existant.»

Ben justement, depuis MacApp et NeXTStep, y a eu le temps de definir des principes de nommage et d'evocations qui evitent les erreurs de jeunesse d'une API. Mine de Rien Cocoa herite directement de ces framework developés dans les annees 80/90.

Si l'idee est de garder l'esprit Smalltalk, pourquoi alors ne pas faire l'inverse d'Objective-C et de purger les scories du C en gardant une syntaxe Smalltalk et en y rajoutant des indicateurs ameliorant la compilation?

« À lire certains avis sur l’évolution de Swift, on a un peu l’impression que le C++11 existait dès 1983. »

J'avais assisté a une conference de Bertrand Meyer il y a fort longtemps qui expliquait de maniere tres interressante la genese de C++ et les principes et objectifs de B.Stroustrup qui l'avait amené a vouloir faire un meilleur C pour les applications industrielles plutot que de construire un autre langage s'affranchissant des handicap de C.
Meyer etait arrivé a la conclusion inverse de Stroustrup en estimant qu'il fallait garder C comme un "assembleur" portable qu'utilisait le compilateur comme langage intermediare (plus efficace que l'approche VM pour les langages compilé) et qu'il fallait au contraire construire un langage le plus propre possible et de haut niveau. Avec cette approche on gardait ainsi la compatibilité avec l'existant et les autres langages et la garantie d'avoir un code optimisé en sortie.

Dans les faits Stroustrup s'etait des le debut attaché a un processus de normalisation - dans le cadre de l'ISO - en amont et les ajouts syntaxiques ce sont fait au fur a mesure des inventions et realisations de nouveaux concepts et principes, qui eux n'existaient pas lors de la creation de C++.

Swift subit des changements majeurs dans sa syntaxe et sa grammaire qui ne sont pas liés a des evolutions de l'etat de l'art, mais qui sont des nettoyages de scories mal pensées ou manques flagrants par rapport a des pratiques et principes bien etablis.

Donc il est totalement irrationnel de comparer l'evolution de C++ avec celle de Swift.

avatar BeePotato | 

@ C1rc3@0rc : « Dans les faits Stroustrup s'etait des le debut attaché a un processus de normalisation - dans le cadre de l'ISO - en amont et les ajouts syntaxiques ce sont fait au fur a mesure des inventions et realisations de nouveaux concepts et principes, qui eux n'existaient pas lors de la creation de C++. »

Elle ne s’est pas faite bien vite, la normalisation !
La situation de C++ avant ça était plutôt chaotique, pas de quoi faire rêver par rapport à la situation qu’on connaît actuellement avec Swift. Mais comme ça commence à être un peu vieux tout ça, on a tendance à ne garder que les bons souvenirs. :-)

« Si l'idee est de garder l'esprit Smalltalk, pourquoi alors ne pas faire l'inverse d'Objective-C et de purger les scories du C en gardant une syntaxe Smalltalk et en y rajoutant des indicateurs ameliorant la compilation? »

Ah, ça, j’avoue que question syntaxe, j’aurais nettement préféré que Swift reste dans la lignée d’Objective-C. Mais bon, apparemment c’est moins vendeur.

« Mais soit Apple fait un langage "glue" pour Cocoa et se le garde, soit Apple fait un langage universel et le detache de Cocoa, parce que Cocoa jusqu'a preuve du contraire ça peut pas exister sur autre chose que MacOS/iOS. »

Sinon, on peut aussi faire la version intermédiaire. Et c’est d’ailleurs ce qu’Apple a fait (en offrant au passage une partie de Cocoa avec Swift). Et ça marche. :-)

avatar fte | 

@BeePotato

C++, je l'ai beaucoup utilisé à une époque où il fallait porter le code d'un compilateur à un autre, car chaque compilateur implémentait son C++ et pas "le C++".

Le code portable, vraiment portable, était constellé de #if ou #ifdef et devait globalement de limiter à du C avec des classes.

Je ne souviens de cette transition de MPW C++ à CodeWarrior. Oh si je m'en souviens !

Quant à la syntaxe de Swift, si elle abandonne la notation héritée de Smalltalk, c'est pour une raison qui a été clairement dite par Lattner : Swift n'est pas un langage orienté objets à passage de messages. Les invocations de fonctions membres sont des appels de méthodes, et non des envois de messages. Il y a des raisons pratiques de chaînage évidemment aussi, les .? en particulier, et d'autres, mais la motivation première était celle dite plus haut.

avatar BeePotato | 

@ fte : « C++, je l'ai beaucoup utilisé à une époque où il fallait porter le code d'un compilateur à un autre, car chaque compilateur implémentait son C++ et pas "le C++" ».

Pareil (enfin, si ce n’est que j’ai évité de « beaucoup » l’utiliser, entre autres pour cette raison).
C’est bien pour ça que ça m’amuse de voir utiliser une telle référence, assortie d’histoires de normalisation « dès le début », pour critiquer l’évolution de Swift qui vise la stabilité pour son troisième anniversaire. :-)

« Quant à la syntaxe de Swift, si elle abandonne la notation héritée de Smalltalk, c'est pour une raison qui a été clairement dite par Lattner : Swift n'est pas un langage orienté objets à passage de messages. Les invocations de fonctions membres sont des appels de méthodes, et non des envois de messages. »

Mouais, c’est vrai qu’il y a cette explication, mais elle ne m’a jamais convaincu : une syntaxe ne dit pas explicitement « envoi de message » ou « appel de méthode », c’est juste qu’on s’est habitué à voir l’une utilisée dans un cadre et l’autre dans l’autre — mais des habitudes, ça se change, et il n’y avait rien d’incompatible entre la syntaxe d’Objective-C et les appels de fonctions. Même chose pour le chaînage.

Mais bon, il faut reconnaître qu’on finit par s’habituer à la syntaxe de Swift, qui a au moins intégré l’étiquetage des arguments, permettant une lisibilité du code largement supérieure à ce qu’on obtient dans d’autres langages (mais légèrement inférieure, à mon avis, à ce qu’on a en Objective-C, où le début du nom d’une méthode ne se trouve pas bizarrement séparé du reste du nom par une parenthèse ouvrante).

Il faut bien dire aussi que si on arrive à s’habituer au C++, on peut se faire à tout. :-)

avatar C1rc3@0rc | 

Faut pas assimiler temps de developpement et dynamique de standardisation.
C++ et Ada prennent du temps pour evoluer et chaque evolution est longuement evaluée pour determiner si elle est légitime ou pas. Une standarisation comme en C++ ou en Ada se construit sur une base saine ou l'on ajoute des elements permettant un meilleur controle, plus de fonctionnalité et de coherence. C'est pas de l'empirisme brouillon comme ce qui semble etre (avoir ete?) le cas de Swift qui casse l'existant d'une version a l'autre. Python qui casse en (petite) partie la continuité de la version 2 a 3 le fait de maniere justifié et y a quand meme 8 ans entre les 2...

La premiere publication d'une reference de C++ date de 1985 mais C++ a ete standarisé ISO en 1998... Car si l'approche de Stroustrup etait rationnelle et suivie (construction par ajout de principes au fur est a mesure qu'ils etaient maitrisés) jusqu'a 1998 Stroustrup n'avait aucun controle sur ce qui se reclamait de C++ et le C++ etait un chantier ou chaque boite qui voulait faire un C a objet sans trop se casser la tete venait prendre ce qu'elle voulait.

La premiere reference a la base de la standarisation date de 1990 et entre 1990 et 1998 C++ a vu l'ajout de principes fondamentaux.

Donc il ne pouvait pas y avoir de C++ standards avant le rachat de Metrowerk par Motorola (1999). Et il me semble que MPW a ete arreté en 2001. Avant il etait question de dialectes de C a objets qui s'inspirait plus ou moins des publications de references de C++ et qui realisaient une partie des fonctions.

C'est totalement différent de Swift bien qu'ayant des elements syntaxiques du C n'est pas une evolution du C au milieu d'autres evolutions tentant de realiser un modele nouveau (ce qui etait le cas des multiples C a objet qui pour la plupart tentaient de pomper sur Object Pascal).

Coté MacOS il y avait aussi le probleme de devoir faire coller C++ a Object Pascal, le langage natif de MacOS et que le Framework MacApp etait lui aussi construit sur Object Pascal et ses spécificités de réalisation.

«Quant à la syntaxe de Swift, si elle abandonne la notation héritée de Smalltalk, c'est pour une raison qui a été clairement dite par Lattner : Swift n'est pas un langage orienté objets à passage de messages. Les invocations de fonctions membres sont des appels de méthodes, et non des envois de messages. »

Lattner a choisi une approche qui est aujourd'hui sur-representée, avec ses avantages (compilation pour une VM plus simple) et inconvenients (gestion du dynamisme et abstraction moins completes), mais qui casse fondamentalement avec la philosophie d'Objective-C depuis les fondements de NeXT.
Donc tu as raison c'est pas qu'une question de notation, mais de paradigme. Les consequences sont immenses et pour les mesurer faut comprendre la différence entre les deux approches.
Le hic c'est que Cocoa est construit sur la philosophie du passage de messages, et que toute la puissance d'interface builder vient de la.
Donc pourquoi, quitte a faire ce choix qui casse les fondements de MacOS, aller sur un nouveau langage et pas utiliser un des multiples utilisant le modèle si classique avec comme choix ultime Java, C#, C++ ou Eiffel par exemple?

avatar emgb | 

Trés cochon ce code sur la capture !

avatar Rictusi | 

Et bien montres nous du joli code. Ca peut toujours servir d'en voir au moins une fois dans sa vie :)

avatar pit-le-rouge | 

perso, je suis passé sous C# depuis les gros efforts fournis par MS sur Mac (et Linux) depuis le rachat de Xamarin. Un langage qui permet de développer sur plusieurs plateformes contrairement à swift. Et qui est aujourd'hui mature.

Pages

CONNEXION UTILISATEUR