[SWIFT] Limitations ?

Eric P. · juillet 2016

Bonjour,

J'envisage la réécriture d'iPocket Draw et ma question est :

Y a-t-il (encore) des limitations avec Swift par rapport à l'objective C ?

D'autre part que pensez-vous des convertisseurs automatiques de code, Objective C -> Swift ?

Bon après-midi !

Joanna Carter · juillet 2016

ça dépendrait sur ce que tu veux faire. Mais, à part de l'introspection, je dirais que je ne rien manque. En revanche, je trouve Swift beaucoup plus flexible et efficace.

Céroce · juillet 2016

J'envisage la réécriture d'iPocket Draw

Pourquoi ne pas effectuer une transition douce, en annotant le code Objective-C, et en développant le nouveau code en Swift ?

Y a-t-il (encore) des limitations avec Swift par rapport à l'objective C ?

Le principal inconvénient est que la syntaxe est encore sujette à pas mal de changements. Tu devras certainement réécrire certains passages quand arrivera Swift 4.
Cela dit, le langage devient de plus en plus mâture et Xcode propose une conversion automatique de Swift 1 à Swift 2. De telles conversions seront présentes pour Swift 3.

FKDEV · juillet 2016

Les limitations de swift par rapport à Objective-C existent.

Par exemple, pour l'instant, il n'y a pas d'équivalent aux KVC/KVO ou à NSSelectorFromString en swift.

Mais, sur iOS ou macOS, on est dans une période de cohabitation dans laquelle tu peux (et tu dois) utiliser des objets qui reposent sur le runtime Objective-C pour t'interfacer avec les frameworks systèmes.

Donc en gros si tu écris du swift pour Objective-C, tu n'as pas ces limitations mais tu n'as pas non plus tous les avantages de swift.

Si tu écris du swift pur, tu auras des limitations par rapport à Objective-C mais tu auras d'autres avantages, c'est un autre langage quoi.

Il faudrait qu'Apple donne un nom à ces différentes variations sur swift car il est difficile d'en parler. Je vois trois cas :

-du swift pur sans Cocoa ni Foundation. Pour l'expérimenter, le mieux est de développer sur Linux sans Foundation pour éviter le bridging automatique vers les classes de Foundation (String -> NSString, etc)

-du swift totalement intégré à Objective-C : ta classe dérive d'une classe Objective-C ou de AnyObject, implémente un protocol Objective-C, ou utilise le mot clé @objc.

-du swift pur qui utilise de l'Objective-C : une classe swift qui utilise par exemple NSURLSession (sans delegate mais uniquement via des blocks).

NiClou · juillet 2016

ça dépendrait sur ce que tu veux faire. Mais, à part de l'introspection, je dirais que je ne rien manque. En revanche, je trouve Swift beaucoup plus flexible et efficace.

respondsToSelector me manque tellement

Magiic · juillet 2016

Pour ma part je ne vois aucune limitations à Swift

En réalité il y a bien des choses qui m'ont ennuyés quand je le compare à l'Objective-c. L'interaction avec les API C sont un exemple. Le changement comme évoquer plus haut entre les versions de Swift aussi.

Après pour KVO/KVC ou l'introspection ça existe sur Swift puisqu'il y a des moyens de faire sensiblement la même chose.

colas_ · juillet 2016

@céroce

Un des objectifs de la v3 de Swift c'est que la syntaxe ne bouge plus (le moins possible) dans les versions suivantes.

Cf. http://ericasadun.com/2016/05/16/winding-down-swift-3-0-abi-stability-deferred/

Edit ils ont pris du retard du coup seront obligés de modifier les fondations et la syntaxe du langage aussi pour la v4

tablier · juillet 2016

Saint Axe priez pour les développeurs ! J'ai quand même des doutes !

Eric P. · juillet 2016

respondsToSelector me manque tellement

J'en ai quelques-uns...

Merci pour vos réponses.

Joanna Carter · juillet 2016

respondsToSelector me manque tellement

Arrêtes de pleurer !

Tu as toujours responds(to:)



@objc protocol NavigationItemConfigurable

{

@objc optional func didTapCancelButton(sender: UIBarButtonItem)

}





extension NavigationItemConfigurable where Self: UIViewController

{

func configureNavigationItem()

{

let dtcb = #selector(didTapCancelButton(sender:))



if responds(to: dtcb)

{

navigationItem.leftBarButtonItem = UIBarButtonItem(barButtonSystemItem: .cancel,

target: self,

action: dtcb)

}

}

}

FKDEV · juillet 2016

Après pour KVO/KVC ou l'introspection ça existe sur Swift puisqu'il y a des moyens de faire sensiblement la même chose.

L'introspection existe mais tu ne peux pas appeler une méthode à partir d'une chaà®ne de caractère. Tu ne peux pas non plus observer n'importe quelle propriété.

Larme · juillet 2016

Le principal inconvénient est que la syntaxe est encore sujette à pas mal de changements. Tu devras certainement réécrire certains passages quand arrivera Swift 4.

Cela dit, le langage devient de plus en plus mâture et Xcode propose une conversion automatique de Swift 1 à Swift 2. De telles conversions seront présentes pour Swift 3.

Ah, je vais sûrement me mettre à Swift quand il arriveras à sa version 4 alors.

En espérant aussi qu'il aura un peu plus de dépendances du CocoaTouch "classic" (car si c'est pour refaire exactement les mêmes lignes et ne pas profiter des flat, map, et autres joyeusetés et faire bêtement de la traduction littérale).

tablier · juillet 2016

Ah, je vais sûrement me mettre à Swift quand il arriveras à sa version 4 alors.

Moi aussi ! ou peut-être attendrais-je la version 5.

J'ai bricolé un peu avec swift, je n'y ai pas trouvé d'intérêt évident autre qu'un rapprochement avec les bibliothèques C (ou C++ ?). Bon, je ne suis qu'un amateur alors j'ai peut-être tort !

Eric P. · juillet 2016

Merci pour vos réponses auxquelles je vais réfléchir pendant mes vacances sans ordinateur.

Céroce · juillet 2016

J'ai bricolé un peu avec swift, je n'y ai pas trouvé d'intérêt évident

Swift est avant tout un langage pragmatique, il n'a rien de révolutionnaire. Personnellement, ce que je trouve intéressant est comment on arrive à implémenter des concepts nouveaux de façon élégante. Par exemple, quand on compare l'implémentation de Reactive Cocoa pour Objective-C et pour Swift, la seconde est bien plus évidente.

Draken · juillet 2016

Ah, je vais sûrement me mettre à Swift quand il arriveras à sa version 4 alors.

Tu sais, la version 8.4 sera encore mieux.

Larme · juillet 2016

Tu sais, la version 8.4 sera encore mieux.

Mouais... La version 8.4 apportera sûrement de gros changements

Non, ce qui je trouvais réellement embêtant, c'est de casser des " mécanismes " très utilisés : NSError management et @selector().

AliGator · juillet 2016

Par exemple, pour l'instant, il n'y a pas d'équivalent aux KVC/KVO ou à NSSelectorFromString en swift.

Le KVC est quand même d'une utilité assez rare, et il existe d'autres moyens plus efficaces en Swft.
Le KVO existe, et surtout tu peux aussi à la place utiliser les willSet/didSet qui sont bien plus efficaces, et bien plus lisibles que de devoir mettre tout le code dans cette méthode observeValueDidChangedOuJeSaisPlusQuoi dégueulasse du KVO ObjC. Donc Je préfère de loin le KVO de Swift ;-)

Pourquoi ne pas effectuer une transition douce, en annotant le code Objective-C, et en développant le nouveau code en Swift ?

+1

Le principal inconvénient est que la syntaxe est encore sujette à pas mal de changements. Tu devras certainement réécrire certains passages quand arrivera Swift 4.
Cela dit, le langage devient de plus en plus mâture et Xcode propose une conversion automatique de Swift 1 à Swift 2. De telles conversions seront présentes pour Swift 3.

Swift 3, qui est en train d'être figé au moment où l'on parle (plus aucune nouvelle proposition qui chargerait le langage et casserait la rétro-compatibilité n'est acceptée à partir de fin Juillet sur la Mailing List officielle publique Swift-Evolution, et à partir de début Août sur la Mailing List les discussions seront à propos de Swift 4 et non plus de Swift 3). Du coup à partir de demain il n'y aura plus de changement de *décidé* pour Swift 3; il y a quand même certaines propositions pour Swift 3 qui ont déjà été acceptées mais restent encore à implémenter par la team Apple et/ou par la communauté, mais le but est que Swift 3 sorte d'ici Xcode 8.

Mais l'information importante surtout c'est que Swift 3 vise la compatibilité de code source. Autant ce que tu aurais pu avoir déjà écrit en Swift 2 il faudra modifier ton code pour qu'il compile avec Swift 3 (bon ceci dit l'assistant de migration et les "Fix-It" de Xcode font 95% du boulot pour toi donc c'est pas si méchant), autant une fois que Swift 3 sera sorti, Swift 4 ne devrait faire que des ajouts de fonctionnalités pour rendre Swift encore plus puissant (surtout par exemple la complétude des Generics pour des usages un peu avancés)

Donc si tu commences avec Swift 3, tu peux être tranquille. Au mieux quand Swift 4 sortira (dans genre un an ?), tu auras des trucs en plus, mais pas de trucs en moins et tu n'auras surtout rien à modifier dans ton code pour que ça marche en Swift 4, car Swift 4 ne fera que de l'additif.

En Bref, c'est le moment idéal pour te mettre à Swift au final.

respondsToSelector me manque tellement

Je ne comprend pas ta remarque. D'une part il existe et est accessible, mais en plus il est totalement inutile avec l'optional chaining qui rend le test d'existence d'une méthode beaucoup plus safe qu'en ObjC (où un oubli de ":" dans le nom du selector ou un copier/coller trop rapide pouvait risquer de ne pas tester pour le même selector que celui qu'on voulait vraiment exécuter)



// Objective-C

if ([object respondsToSelector:@selector(totoDidFinish]) {

[object totoDidFinish:YES];

}

// Oups, en plus ça va pas marcher là  car j'ai fait une erreur, j'ai oublié les ":" dans le nom du selector !



// Swift

object.totoDidFinish?(YES) // Le "?" suffit pour dire "si la méthode existe, exécute là , sinon ne fait rien".

colas_ · juillet 2016

Je m'étais basé sur cette phrase de Lattner pour dire que la v4 introduirait des incompatibilités.

That said, it is also clear at this point that some of the loftier goals that we started out with aren't going to fit into the release â€“ including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the highest priority features to get done.

(prise sur http://ericasadun.com/2016/05/16/winding-down-swift-3-0-abi-stability-deferred/)

Mais j'ai dû mal comprendre ABI. Quelqu'un serait capable d'expliquer ce que c'est ?

Cf. http://stackoverflow.com/questions/3784389/difference-between-api-and-abi

Céroce · juillet 2016

En gros l'ABI, c'est la manière dont on passe les paramètres et on appelle les fonctions. Apple a pris un peu de temps pour la standardiser. (Entre nous, c'est pas plus mal, ça évite de devoir bidouiller ensuite).

Le fait qu'elle ne soit pas figée pose deux problèmes (qui étaient vachement bien expliqués dans un article que je ne trouve plus).
- on ne peut pas utiliser des bibliothèques précompilées, puisque selon la version du langage, ça peut ne pas communiquer
- il faut livrer la framework du langage avec l'appli, parce que ça dépend en quelle version de Swift elle a été écrite.

Disons qu'à notre niveau, le fait que l'ABI ne soit pas encore figée n'est pas un gros problème. ça ennuie surtout Facebook avec leur appli archi complexe qu'ils compilent par bouts parce que sinon, ils y passent la nuit.

FKDEV · juillet 2016

Le KVC est quand même d'une utilité assez rare, et il existe d'autres moyens plus efficaces en Swft.

Le KVO existe, et surtout tu peux aussi à la place utiliser les willSet/didSet qui sont bien plus efficaces, et bien plus lisibles que de devoir mettre tout le code dans cette méthode observeValueDidChangedOuJeSaisPlusQuoi dégueulasse du KVO ObjC. Donc Je préfère de loin le KVO de Swift ;-)

Le KVC et KVO existe mais uniquement en utilisant le runtime Objective-C, non ?

Je pense que si on veut tirer pleinement parti de Swift dans l'avenir, et notamment, du côté multi-plateforme, il faut bien comprendre ce qui vient de Swift (et de la Swift Standard Library) et ce qui vient de NSFoundation et Objective-C. Ce n'est pas toujours très clair.

Le KVC (ou une reflection qui ne soit pas que read-only) permet quand même les mécanismes de type Binding ou des serialisations un peu automatisées. On peut s'en passer mais il faut avouer que pour l'instant, c'est une limitation pour une programmeur qui viendrait de l'Objective-C.

On peut refaire un équivalent du KVO avec les properties de Swift mais un des avantages des KVO c'est que cela fonctionne à travers les libraires. Par exemple tu peux observer la propriété selected d'un MKAnnotation, même si cela n'a pas été prévu. D'ailleurs je ne connais pas d'autres langages où cela est possible.

Mon avis, c'est qu'il faudra que Swift se dote d'un mécanisme qui permettent de lire/écrire une property à partir de son nom. Quitte à ce que cela passe par un protocol qu'il faudra implémenter soi-même. C'est un must-have pour un langage moderne.

Après l'absence KVO généralisé, c'est moins grave, mais là encore cela peut passer par un protocol proposé dans la Swift Standard Library.

Jérémy · août 2016

Pourquoi ne pas effectuer une transition douce, en annotant le code Objective-C, et en développant le nouveau code en Swift ?

Effectivement pour une application existente, il vaut mieux migrer en douceur plutôt que perdre des heures pour arriver au même résultat. En revanche pour un nouveau projet, vous conseillez l'emploi de Swift ou Objective-C ?

NiClou · août 2016

Effectivement pour une application existente, il vaut mieux migrer en douceur plutôt que perdre des heures pour arriver au même résultat. En revanche pour un nouveau projet, vous conseillez l'emploi de Swift ou Objective-C ?

Pour ne travailler plus qu'exclusivement en Swift je pense que oui. Si tu savais le nombre d'app grand public développé en swift

Jérémy · août 2016

Pour ne travailler plus qu'exclusivement en Swift je pense que oui. Si tu savais le nombre d'app grand public développé en swift

Pour les apps pro ce n'est pas conseillé ?

Céroce · août 2016

Pour les apps pro ce n'est pas conseillé ?

Ce n'est pas une question de "pro" ou "grand public", mais plutôt de taille de l'appli. Comme je l'expliquais, on ne peut pas encore linker les modules compilés séparément, et ça pose problème pour les grosses applications.

[SWIFT] Limitations ?

Réponses