Xcode 6 Beta 4 est de sortie, et entre autres nouveautés, l'arrivée des Access Control, c'est à dire la possibilité de définir une déclaration "private" ou "public" ou "internal" !!
De la phase Beta de Xcode6, oui, certainement. Comme pour chaque beta Xcode, ça ne dure que l'été, entre l'annonce à la WWDC et l'annonce de nouveau matériel à la rentrée ou vers mid-T4. Donc d'ici septembre Xcode6 sera en GM, comme d'hab.
Fin de la phase de beta de l'ABI Swift, par contre, non, puisque comme ils l'ont annoncé, qu'on arrête pas de le répéter ici, et qu'Apple le répète également sur le Blog de Swift, les ABI (Binary Interfaces) font continuer d'évoluer selon les retours des utilisateurs pendant quelques années. Ca n'empêche pas que le compilateur va se stabiliser en même temps que la sortie d'Xcode6 et qu'on pourra espérer coder en Swift de façon stable d'ici à T4-2014 mais ça veut aussi dire qu'il faut prévoir des petits changements sur l'ABI (et peut-être qques éléments de syntaxe mineurs ?) s'étaler sur la période de l'année à venir au moins (voir l'article de Blog d'Apple à ce sujet)
Comme pour beaucoup d'entre vous j'ai été partagé sur cette annonce d'un nouveau langage de programmation. Alors que je commençais tout juste a être à l'aise en objective-c (bien que je ne maà®trise pas tous les concepts) voilà une techno qui mérite de s'y mettre pleinement bien qu'elle soit peu stable encore.
Je n'ai pas autant d'expériences que vous dans la programmation mais voir un outil comme le Playground c'est génial ! Les tuples et binding sont aussi des éléments qui font apprécier Swift mais clairement ce dernier est très loin de ressembler à l'objective-c.
En tout cas, s'il permet d'être 4 fois plus rapide que l'objective-c, ça annonce du bon pour les applications futures.
En tout cas, s'il permet d'être 4 fois plus rapide que l'objective-c, ça annonce du bon pour les applications futures.
Ca c'est un argument marketing, car ce gain de performance ne sera effectifs que pour des types d'algorithmes bien précis. Si en moyenne on obtient un gain de performance de 1.5 ça sera déjà bien...
Ca c'est un argument marketing, car ce gain de performance ne sera effectifs que pour des types d'algorithmes bien précis. Si en moyenne on obtient un gain de performance de 1.5 ça sera déjà bien...
Quand il parlait de rapidité, j'ai compris rapidité de développement et non performance.
Si c'est effectivement un langage plus rapide que son predecesseur, c'est une révolution.
Car jusqu'à maintenant, en tant que développeurs, nous avons toujours accepté des pertes de vitesses en echange d'un plus haut niveau d'abstraction. Les pertes de vitesse étant compensés par la progression des micro-processeurs.
Je pense que le langage ne prendra sa vitesse de croisière qu'avec l'arrivée de frameworks en interface swift. En attendant s'il faut faire des casts dynamiques et des conversions de types dans tous les sens, cela risque de plomber les perfs réelles, non ?
Autre question : sera-t-il possible d'avoir des frameworks à double interface swift+objective-c ?
Si c'est effectivement un langage plus rapide que son predecesseur, c'est une révolution. Car jusqu'à maintenant, en tant que développeurs, nous avons toujours accepté des pertes de vitesses en echange d'un plus haut niveau d'abstraction. Les pertes de vitesse étant compensés par la progression des micro-processeurs.
Voir l'article de Mike Ash à ce sujet. En résumé, pour l'instant l'ABI comme le compilateur Swift ne sont pas encore dans leur version finale donc il y a encore de la place pour optimiser, ça va venir avec les futures releases.
Je pense que le langage ne prendra sa vitesse de croisière qu'avec l'arrivée de frameworks en interface swift. En attendant s'il faut faire des casts dynamiques et des conversions de types dans tous les sens, cela risque de plomber les perfs réelles, non ?
En effet, c'est clair que si du code Swift appelle du code Objective-C, et donc finit par re-dépendre du dispatch dynamique (via objc_msgSend), ça fait goulot d'étranglement. Si tu testes sur du code en Swift pur sans aucune interaction avec les objets du runtime et de la lib ObjC et sans aucun bridging, tu n'auras pas cette perte de performance due au cast et au dispatch dynamique.
En ObjC le dispatch de méthodes est dynamique et résolu au runtime par des algos de recherche d'implémentations pour un @selector donné. Car ObjC permet de rajouter des méthodes à des classes à la volée même au moment du Runtime, ou de faire du swizzling, etc, donc de changer l'implémentation d'une méthode même après compilation. En Swift ce n'est pas le cas, une fois le code compilé une implémentation associée à une méthode restera figée. Cela permet d'implémenter les appels de méthodes via des dispatch tables (vtable, un peu comme en C++) qui sont juste des tableaux C contenant le pointeur vers l'implémentation. Du coup la résolution d'une méthode (trouver son implémentation à partir de la méthode appelée et de la classe de l'objet) est beaucoup plus rapide dans ce cas qu'en ObjC.
Autre question : sera-t-il possible d'avoir des frameworks à double interface swift+objective-c ?
Que veux-tu dire par là ? Les APIs sont automatiquement traduites via le bridging déjà . - Tu voudrais fournir deux implémentations différentes dans ton framework, une pour Swift et une pour ObjC, avec la même API/interface ? Si oui l'intérêt est minimum je trouve et la galère que ça va générer en terme de maintenance insupportable. - Tu voudrais fournir deux interfaces différentes pour Swift et pour ObjC, mais qui au final pointent toutes les 2 sur la même implémentation, juste avec les noms des méthodes un peu plus adaptés mais au final avec les mêmes paramètres ? La traduction automatique des interfaces ObjC<->Swift est déjà plutôt pas mal faite de ce côté, et si tu veux vraiment faire 2 interfaces distinctes, tu pourrais toujours imaginer 2 wrappers, chacune avec leur interface adaptée, qui finissent par appeler la même implémentation. Mais je suis pas sûr de l'intérêt au final...
Je pensais surtout aux frameworks fournis par Apple.
En fait, ce qui me paraitrait bon pour l'adoption du langage dans le futur c'est qu'Apple puisse fournir un seul framework qui puisse être utilisé de manière transparente dans les deux langages, et sans pénalité pour swift.
Sauf que toi tu voudrais le "sans pénalité pour Swift" en plus, c'est à dire qu'Apple réimplémente tous ses frameworks tout en Swift pur, en utilisant des objets Swift uniquement et plus du tout d'objet ObjC, de sorte que quand on les utilise en Swift il n'y ait plus besoin de bridging et que tout soit en Swift natif, c'est ça ?
Dans ce cas ça veut dire qu'Apple devra continuer à maintenir 2 implémentations de chaque framework, une en ObjC et une en Swift ? Et qu'à chaque fois qu'ils vont faire évoluer un framework pour y ajouter des fonctionnalités, faudra qu'ils l'implémentent dans les 2 langages (du moins pendant qques années encore avant d'abandonner l'implémentation ObjC au final) ? Ca risque d'être un travail monstre, avec une maintenabilité casse-gueule, et un risque aussi d'avoir des comportements différents ou bugs dans l'implémentation Swift et pas dans l'implémentation ObjC...
Sauf que toi tu voudrais le "sans pénalité pour Swift" en plus, c'est à dire qu'Apple réimplémente tous ses frameworks tout en Swift pur, en utilisant des objets Swift uniquement et plus du tout d'objet ObjC, de sorte que quand on les utilise en Swift il n'y ait plus besoin de bridging et que tout soit en Swift natif, c'est ça ?
Oui.
Dans ce cas ça veut dire qu'Apple devra continuer à maintenir 2 implémentations de chaque framework, une en ObjC et une en Swift ?
Ah ben non...
Non il faudrait une interface Objective-C vers ce framework, mais si c'est pas possible, tant pis.
Bien-sûr cette interface risquerait de ne pas être à 100% compatible avec les précédents frameworks. Par exemple, le method swizzling ne fonctionnerait plus. Si c'est pas possible, c'est pas possible...
En tous cas il va falloir trouver un truc pour faire la transition des frameworks sinon swift ne décollera pas.
Tu voudrais qu'apple porte l'implémentation de ses frameworks en Swift et abandonne du coup totalement l'implémentation en Objective-C (parce qu'ils ne vont pas maintenir 2 implémentations de chaque framework, donc). Et que ce framework codé uniquement en Swift ait à la fois une interface accessible évidemment en Swift, mais aussi une interface accessible en ObjC ?
Bah là encore, c'est déjà possible avec le Bridging cette traduction automatique de l'API/interface Swift en interface/API ObjC, ça se fait à la volée. Le seul truc qui manque si c'est ça que tu attends, c'est qu'Apple réécrive tous ses frameworks existants en Swift, et abandonne leur implémentation en ObjC (pour pas avoir 2 implémentations à maintenir). Ca se fera certainement, mais sur le (très?) long terme.
Il était question d'un OS écrit entièrement en Swift. Peut-on s'attendre d'ici quelques années à un OSX écrit en Swift ? D'ailleurs il y a quoi dans la recette d'OSX actuellement ? Un mixte d'obj-c et de c++ ?
Il étais question d'un OS écrit entièrement en Swift. Peut-on s'attendre d'ici quelques années à un OSX écrit en Swift ? D'ailleurs il y a quoi dans la recette d'OSX actuellement ? Un mixte d'obj-c et de c++ ?
Bah là encore, c'est déjà possible avec le Bridging cette traduction automatique de l'API/interface Swift en interface/API ObjC, ça se fait à la volée. Le seul truc qui manque si c'est ça que tu attends, c'est qu'Apple réécrive tous ses frameworks existants en Swift, et abandonne leur implémentation en ObjC (pour pas avoir 2 implémentations à maintenir). Ca se fera certainement, mais sur le (très?) long terme.
Bah voila, c'est ça. En tous cas j'aimerais bien connaà®tre la stratégie prévu par Apple pour la gestion des frameworks.
Bah migration au fil de l'eau, au fur et à mesure des versions d'iOS, entre maintenant et dans 2 ans à peu près, d'ici à ce que Swift, son langage et son ABI soient stabilisés quoi.
Bref, un peu comme pour les autres migrations, genre Carbon->Cocoa, PPC->i386, MRR->ARC et tout ça. Au fur et à mesure des années ça va se convertir, comme d'hab quoi. Je vois pas pourquoi ils feraient autrement en fait.
Quand je lis des trucs sur swift, j'ai l'impression (probablement fausse) que c'est de l'Objective-C écrit autrement.
Donc je me pose la question: quelle est réellement la différence avec Objective-C, a part la syntaxe?
Ce n'est pas de l'Objective-C écrit autrement, pour plusieurs raisons :
- Swift à des fonctionnalités qu'ObjC n'a pas (Generics, Optionals, enums avec Associated Value, ...)
- ObjC est une sur couche du C. Tu peut le voir comme du sucre syntaxique pour faire de l'Objet en C. Alors que Swift est pur Objet : il n'y a plus de notions de pointeurs, ce n'est pas une sur couche qui est traduite en C avant d'être compilée comme ObjC mais bien un langage à lui tout seul indépendant. Swift étant conçu pour être pur Objet dès le départ, même les types primitifs comme Int sont des types objet de première classe (en ObjC les objets sont en fait des Struct C sous le capot)
- Swift n'est pas dynamique comme ObjC. Ce qui veut dire que la dispatch table est résolu à la compilation. Ce qui évite tous les mécanismes nécessaires au Runtime en ObjC comme objc_msgSend() appelé sous le capot à chaque fois que tu appelles une méthode en ObjC, juste pour résoudre le dispatch du message et appeler la bonne implémentation de méthode. Alors qu'en Swift tout cela est résolu à la compilation et est unique.
J'oublie certainement d'autres différences encore mais tout cela fait que Swift est bien un langage autonome à part entière et non pas un autre sucre syntaxique pour générer la même chose qu'ObjC (d'ailleurs leurs ABI sont différentes aussi, rien que pour pouvoir supporter le tout objet, les Generics, les Optionals et tout).
C'est plutôt ObjC qui était du sucre syntaxique, sorte de bidouille pour faire de l'objet en C mais qui gardait tous les risques du C (manips de pointeurs bas niveau etc)
Au final la raison pour laquelle Swift à été écrit c'est pour avoir un langage tout objet et safe, mais aussi moderne et pensé dès le début pour supporter toutes ces fonctionnalités en repartant d'une feuille blanche, plutôt que de rajouter encore et encore des sur couches aux langages existants et qu'ils deviennent des mille-feuilles basés sur des fondations qui commencent à dater.
----
C'est pour moi exactement la même chose que quand on est passé de GCC à LLVM. Pourquoi réécrire un nouveau compilateur plutôt que de faire évoluer l'existant GCC ? Parce que GCC était devenu un empilage de couches et un gros plat de spaghettis au fil des années, le rendant difficilement maintenable et évolutif car il n'avait pas été pensé dès le départ pour évoluer autant et finir avec autant de couches.
C'est comme quand tu changes la tapisserie chez toi, tu peux juste coller un nouveau papier peint par dessus l'ancien, puis en recoller encore un autre par dessus... ça va marcher mais à un moment donné faudra quand même mieux tout gratter et repartir d'un mur nettoyé et réagréé plutôt que rajouter une N-ième couche, surtout si c'est pour mettre de la toile ou de la peinture plutôt que de la tapisserie, ce qui n'avait pas été prévu au départ.
C'est comme quand tu changes la tapisserie chez toi, tu peux juste coller un nouveau papier peint par dessus l'ancien, puis en recoller encore un autre par dessus... ça va marcher mais à un moment donné faudra quand même mieux tout gratter et repartir d'un mur nettoyé et réagréé plutôt que rajouter une N-ième couche, surtout si c'est pour mettre de la toile ou de la peinture plutôt que de la tapisserie, ce qui n'avait pas été prévu au départ.
T'es allé la chercher loin cette comparaison là !
Le seul problème c'est le jour où tu dois enlever les 5 couches sur ton projet.
JE ne colle jamais du papier peint sur une ancienne couche de papier peint! JAMAIS! Pour avoir enlevé trois couches de papier dans un appartement ou j'emménageais, j'ai immédiatement appris ce qu'il fallait faire.
Même si je ne suis pas vraiment compétent en Obc-C, bien que je commençais a bien naviguer dans Cocoa, par contre en matière de bâtiment d'avantage...
Un réagrége ne sert a rien d'autre que de rendre la surface plane et prête a recevoir une finition, 5 couches de papiers peint ne posent pas forcément de problème, sauf si une couche de peinture a été mise dessus... Bref
Je suis cette discussion toujours avec beaucoup d'intérêt Obj-C ou pas je ne vois pas le problème, forcément que quelque part il en est issus puisque même il en utilise les classes et heureusement sinon tout l'acquit serait perdu...
N'auriez vous pas tendance a faire une montagne de cas particuliers ?
J'ai toujours pensé et je pense toujours qu'il était bien préférable de rester au pus des classes Cocoa, disons natives, que de s'en éloigner. Faut quant même reconnaitre a Apple que les évolutions sont constantes...
Réponses
ça va vite quand-même !
Si tôt ?
Fin de la phase de beta de l'ABI Swift, par contre, non, puisque comme ils l'ont annoncé, qu'on arrête pas de le répéter ici, et qu'Apple le répète également sur le Blog de Swift, les ABI (Binary Interfaces) font continuer d'évoluer selon les retours des utilisateurs pendant quelques années. Ca n'empêche pas que le compilateur va se stabiliser en même temps que la sortie d'Xcode6 et qu'on pourra espérer coder en Swift de façon stable d'ici à T4-2014 mais ça veut aussi dire qu'il faut prévoir des petits changements sur l'ABI (et peut-être qques éléments de syntaxe mineurs ?) s'étaler sur la période de l'année à venir au moins (voir l'article de Blog d'Apple à ce sujet)
D'ailleurs ça a été annoncé à la WWDC.
salut !
Comme pour beaucoup d'entre vous j'ai été partagé sur cette annonce d'un nouveau langage de programmation. Alors que je commençais tout juste a être à l'aise en objective-c (bien que je ne maà®trise pas tous les concepts) voilà une techno qui mérite de s'y mettre pleinement bien qu'elle soit peu stable encore.
Je n'ai pas autant d'expériences que vous dans la programmation mais voir un outil comme le Playground c'est génial ! Les tuples et binding sont aussi des éléments qui font apprécier Swift mais clairement ce dernier est très loin de ressembler à l'objective-c.
En tout cas, s'il permet d'être 4 fois plus rapide que l'objective-c, ça annonce du bon pour les applications futures.
Ca c'est un argument marketing, car ce gain de performance ne sera effectifs que pour des types d'algorithmes bien précis. Si en moyenne on obtient un gain de performance de 1.5 ça sera déjà bien...
Quand il parlait de rapidité, j'ai compris rapidité de développement et non performance.
Car jusqu'à maintenant, en tant que développeurs, nous avons toujours accepté des pertes de vitesses en echange d'un plus haut niveau d'abstraction. Les pertes de vitesse étant compensés par la progression des micro-processeurs.
Je pense que le langage ne prendra sa vitesse de croisière qu'avec l'arrivée de frameworks en interface swift. En attendant s'il faut faire des casts dynamiques et des conversions de types dans tous les sens, cela risque de plomber les perfs réelles, non ?
Autre question : sera-t-il possible d'avoir des frameworks à double interface swift+objective-c ?
En effet, c'est clair que si du code Swift appelle du code Objective-C, et donc finit par re-dépendre du dispatch dynamique (via objc_msgSend), ça fait goulot d'étranglement.
Si tu testes sur du code en Swift pur sans aucune interaction avec les objets du runtime et de la lib ObjC et sans aucun bridging, tu n'auras pas cette perte de performance due au cast et au dispatch dynamique.
En ObjC le dispatch de méthodes est dynamique et résolu au runtime par des algos de recherche d'implémentations pour un @selector donné. Car ObjC permet de rajouter des méthodes à des classes à la volée même au moment du Runtime, ou de faire du swizzling, etc, donc de changer l'implémentation d'une méthode même après compilation. En Swift ce n'est pas le cas, une fois le code compilé une implémentation associée à une méthode restera figée. Cela permet d'implémenter les appels de méthodes via des dispatch tables (vtable, un peu comme en C++) qui sont juste des tableaux C contenant le pointeur vers l'implémentation. Du coup la résolution d'une méthode (trouver son implémentation à partir de la méthode appelée et de la classe de l'objet) est beaucoup plus rapide dans ce cas qu'en ObjC.
Que veux-tu dire par là ? Les APIs sont automatiquement traduites via le bridging déjà .
- Tu voudrais fournir deux implémentations différentes dans ton framework, une pour Swift et une pour ObjC, avec la même API/interface ? Si oui l'intérêt est minimum je trouve et la galère que ça va générer en terme de maintenance insupportable.
- Tu voudrais fournir deux interfaces différentes pour Swift et pour ObjC, mais qui au final pointent toutes les 2 sur la même implémentation, juste avec les noms des méthodes un peu plus adaptés mais au final avec les mêmes paramètres ? La traduction automatique des interfaces ObjC<->Swift est déjà plutôt pas mal faite de ce côté, et si tu veux vraiment faire 2 interfaces distinctes, tu pourrais toujours imaginer 2 wrappers, chacune avec leur interface adaptée, qui finissent par appeler la même implémentation. Mais je suis pas sûr de l'intérêt au final...
Merci pour ta réponse.
Je pensais surtout aux frameworks fournis par Apple.
En fait, ce qui me paraitrait bon pour l'adoption du langage dans le futur c'est qu'Apple puisse fournir un seul framework qui puisse être utilisé de manière transparente dans les deux langages, et sans pénalité pour swift.
Sauf que toi tu voudrais le "sans pénalité pour Swift" en plus, c'est à dire qu'Apple réimplémente tous ses frameworks tout en Swift pur, en utilisant des objets Swift uniquement et plus du tout d'objet ObjC, de sorte que quand on les utilise en Swift il n'y ait plus besoin de bridging et que tout soit en Swift natif, c'est ça ?
Dans ce cas ça veut dire qu'Apple devra continuer à maintenir 2 implémentations de chaque framework, une en ObjC et une en Swift ? Et qu'à chaque fois qu'ils vont faire évoluer un framework pour y ajouter des fonctionnalités, faudra qu'ils l'implémentent dans les 2 langages (du moins pendant qques années encore avant d'abandonner l'implémentation ObjC au final) ? Ca risque d'être un travail monstre, avec une maintenabilité casse-gueule, et un risque aussi d'avoir des comportements différents ou bugs dans l'implémentation Swift et pas dans l'implémentation ObjC...
Oui.
Ah ben non...
Non il faudrait une interface Objective-C vers ce framework, mais si c'est pas possible, tant pis.
Bien-sûr cette interface risquerait de ne pas être à 100% compatible avec les précédents frameworks. Par exemple, le method swizzling ne fonctionnerait plus.
Si c'est pas possible, c'est pas possible...
En tous cas il va falloir trouver un truc pour faire la transition des frameworks sinon swift ne décollera pas.
Tu voudrais qu'apple porte l'implémentation de ses frameworks en Swift et abandonne du coup totalement l'implémentation en Objective-C (parce qu'ils ne vont pas maintenir 2 implémentations de chaque framework, donc). Et que ce framework codé uniquement en Swift ait à la fois une interface accessible évidemment en Swift, mais aussi une interface accessible en ObjC ?
Bah là encore, c'est déjà possible avec le Bridging cette traduction automatique de l'API/interface Swift en interface/API ObjC, ça se fait à la volée. Le seul truc qui manque si c'est ça que tu attends, c'est qu'Apple réécrive tous ses frameworks existants en Swift, et abandonne leur implémentation en ObjC (pour pas avoir 2 implémentations à maintenir). Ca se fera certainement, mais sur le (très?) long terme.
Bah voila, c'est ça.
En tous cas j'aimerais bien connaà®tre la stratégie prévu par Apple pour la gestion des frameworks.
Bref, un peu comme pour les autres migrations, genre Carbon->Cocoa, PPC->i386, MRR->ARC et tout ça. Au fur et à mesure des années ça va se convertir, comme d'hab quoi. Je vois pas pourquoi ils feraient autrement en fait.
Pour mettre mon grain de sel également:
Swift est un nouveau langage. Ce que je n'arrive pas à voir c'est la nécessité de le faire.
Suivant la légende, le C a été écrit par Kernighan et Richie pour avoir l'outil qui leur a permis d'écrire le premier UNIX.
Avec l'avénement de la POO, sont sortis C++ et Objective-C. Langage qui ont évolué par la suite.
Quand je lis des trucs sur swift, j'ai l'impression (probablement fausse) que c'est de l'Objective-C écrit autrement.
Donc je me pose la question: quelle est réellement la différence avec Objective-C, a part la syntaxe?
- Swift à des fonctionnalités qu'ObjC n'a pas (Generics, Optionals, enums avec Associated Value, ...)
- ObjC est une sur couche du C. Tu peut le voir comme du sucre syntaxique pour faire de l'Objet en C. Alors que Swift est pur Objet : il n'y a plus de notions de pointeurs, ce n'est pas une sur couche qui est traduite en C avant d'être compilée comme ObjC mais bien un langage à lui tout seul indépendant. Swift étant conçu pour être pur Objet dès le départ, même les types primitifs comme Int sont des types objet de première classe (en ObjC les objets sont en fait des Struct C sous le capot)
- Swift n'est pas dynamique comme ObjC. Ce qui veut dire que la dispatch table est résolu à la compilation. Ce qui évite tous les mécanismes nécessaires au Runtime en ObjC comme objc_msgSend() appelé sous le capot à chaque fois que tu appelles une méthode en ObjC, juste pour résoudre le dispatch du message et appeler la bonne implémentation de méthode. Alors qu'en Swift tout cela est résolu à la compilation et est unique.
J'oublie certainement d'autres différences encore mais tout cela fait que Swift est bien un langage autonome à part entière et non pas un autre sucre syntaxique pour générer la même chose qu'ObjC (d'ailleurs leurs ABI sont différentes aussi, rien que pour pouvoir supporter le tout objet, les Generics, les Optionals et tout).
C'est plutôt ObjC qui était du sucre syntaxique, sorte de bidouille pour faire de l'objet en C mais qui gardait tous les risques du C (manips de pointeurs bas niveau etc)
Au final la raison pour laquelle Swift à été écrit c'est pour avoir un langage tout objet et safe, mais aussi moderne et pensé dès le début pour supporter toutes ces fonctionnalités en repartant d'une feuille blanche, plutôt que de rajouter encore et encore des sur couches aux langages existants et qu'ils deviennent des mille-feuilles basés sur des fondations qui commencent à dater.
----
C'est pour moi exactement la même chose que quand on est passé de GCC à LLVM. Pourquoi réécrire un nouveau compilateur plutôt que de faire évoluer l'existant GCC ? Parce que GCC était devenu un empilage de couches et un gros plat de spaghettis au fil des années, le rendant difficilement maintenable et évolutif car il n'avait pas été pensé dès le départ pour évoluer autant et finir avec autant de couches.
C'est comme quand tu changes la tapisserie chez toi, tu peux juste coller un nouveau papier peint par dessus l'ancien, puis en recoller encore un autre par dessus... ça va marcher mais à un moment donné faudra quand même mieux tout gratter et repartir d'un mur nettoyé et réagréé plutôt que rajouter une N-ième couche, surtout si c'est pour mettre de la toile ou de la peinture plutôt que de la tapisserie, ce qui n'avait pas été prévu au départ.
T'es allé la chercher loin cette comparaison là !
Le seul problème c'est le jour où tu dois enlever les 5 couches sur ton projet.
JE ne colle jamais du papier peint sur une ancienne couche de papier peint! JAMAIS! Pour avoir enlevé trois couches de papier dans un appartement ou j'emménageais, j'ai immédiatement appris ce qu'il fallait faire.
@Aligator
Comme ça c'est clair! Mais j'attends quand même une réalisation (assez) définitive pour voir ce que ça donne.
Même si je ne suis pas vraiment compétent en Obc-C, bien que je commençais a bien naviguer dans Cocoa, par contre en matière de bâtiment d'avantage...
Un réagrége ne sert a rien d'autre que de rendre la surface plane et prête a recevoir une finition, 5 couches de papiers peint ne posent pas forcément de problème, sauf si une couche de peinture a été mise dessus... Bref
Je suis cette discussion toujours avec beaucoup d'intérêt Obj-C ou pas je ne vois pas le problème, forcément que quelque part il en est issus puisque même il en utilise les classes et heureusement sinon tout l'acquit serait perdu...
N'auriez vous pas tendance a faire une montagne de cas particuliers ?
J'ai toujours pensé et je pense toujours qu'il était bien préférable de rester au pus des classes Cocoa, disons natives, que de s'en éloigner. Faut quant même reconnaitre a Apple que les évolutions sont constantes...
Les développeurs français boivent du thé ? Le ciel tombe !