Petite librairie Swift d'opérateurs que j'utilise
Pyroh
Membre
Salut à tous,
J'ai compilé quelques opérateurs que j'utilise au jour le jour. C'est pour Swift, je vous laisse regarder.
Fendez-vous d'une pull request si vous avez aussi ce genre d'opérateur dans vos codes et que vous avez envie de le partager. 😃
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Assez sympa!
Merci pour le partage
Par contre j'ai pas compris pourquoi pour macOS tu import Foundation (Ok pour moi) et pour iOS (CoreGraphics ??)
#if !os(macOS)
import CoreGraphics
#else
import Foundation
#endif
Merci !
De rien
C'est à cause de
CGFloatqui est dans Foundation sur macOS mais dans CoreGraphics ailleurs.Chacun fait ce qu'il veut dans ses projets persos. Mais, utiliser ce genre d'opérateurs, c'est un peu comme lécher la barre du métro en ce moment.
On est d'accord sur ce principe et c'est pour ça que j'ai fait gaffe de créer des opérateurs très génériques qui ne dépendent pas forcément d'un contexte précis. J'en utilise d'autres plus spécifiques en interne qui n'ont pour le coup aucun intérêt à être distribués.
Ça fait par contre surgir cette question mainte fois posée qui consiste à se demander si il faut se limiter uniquement à la STDLIB et aux frameworks officiels ou si au contraire on va utiliser des librairies tierces. Par exemple Alamofire. C'est une librairie énormément utilisée —SAP l'utilise ou du moins l'utilisait dans son SDK iOS— mais c'est aussi prendre un risque au final. Il y a aussi beaucoup de librairies de gestion des contraintes UI/AppKit faut-il les utiliser ? La majorité des équipes de dev iOS utilisent CocoaPods et beaucoup de gros projets nécessitent ce dernier est-ce un risque pour autant ?
C'est compliqué et ce genre d'idée arrêtée m'a plutôt l'air d'être de l'ordre du dogmatisme plus qu'autre chose. Ce qui est respectable en soit, ne me fait pas dire ce que je n'ai pas dit 😉
Pour ma part j'ai choisi de n'utiliser du code tierce partie à l'unique condition que je le comprenne et que je puisse le débugger pour ne pas me retrouver comme une poule devant une fourchette quand il cessera d'être maintenu.
Maintenant dans ce cas précis l'objet est surtout de partager du code, faire vivre le forum et renforcer —un peu— ma présence sur GitHub.
PS: Lécher la barre du métro c'est toujours une mauvaise idée, COVID19 ou pas 😉
Dogmatique c'est un peu fort. je préfère parler de principes.
Les principes contrairement aux dogmes peuvent être remis en cause. Les principes sont utiles pour éduquer et pour ne pas retomber toujours sur les mêmes problèmes.
Une fois qu'on a compris de quel danger nous protège le principe, on peut, et on doit, le remettre en cause en fonction des situations réelles.
Le problème c'est que certaines personnes n'arrivent pas à se détacher des principes (par peur ou par méconnaissance pathologique du réel). Le principe devient alors un préjugé, ou un dogme.
Par exemple, quand on dit n'utilisez pas le "goto", ça doit être un principe pas un dogme. En fait on peut très bien l'utiliser dans certains cas mais on préfère dire à un débutant de ne pas le faire pour qu'il apprenne à faire des boucles avec des opérateurs plus adaptés à cela.
Pour faire du code de production, en équipe, je pense que c'est bien d'avoir quelques principes.
Dans le cas des opérateurs, on est dans le débat implicite vs explicite, plutôt que sur l'utilisation de bibliothèques tierces-partie.
Un principe que j'ai, c'est que je préfère "toujours" la solution explicite.
Créer un opérateur c'est toujours favoriser l'implicite.
Un symbole d'opérateur ne dit pas toujours bien ce qu'il fait. Je préfère une fonction bien nommée qui ne nécessite pas d'apprentissage inutile.
Cependant, si l'opérateur est compris par tous et permet de gagner du temps dans des écritures répétitives, ça devient une convention et je ne suis pas forcément contre, même si j'en ai jamais eu l'utilité.
J'imagine que si on doit retranscrire des équations mathématique, par exemple, ça peut être utile.
Mais si c'est juste pour faire des one-liners de la mort, je suis contre, même si je comprends que cela peut être jouissif.
En ce qui concerne les bibliothèques, je suis à priori contre, sauf quand je ne peux pas faire autrement ou qu'il s'agit vraiment de ne pas réinventer la roue. Mais dans tous les cas il y a toujours des risques à utiliser une bibliothèque (on a déjà assez de problèmes avec les SDK Apple).
Et honnêtement, je ne comprends vraiment pas l'intérêt de bibliothèques comme Alamo Fire.
Ce que tu dis sur les bibliothèques est vrai.
Quand j'utilise une bibliothèque j'aime bien qu'elle soit open-source aussi.
J'aime bien aussi la décortiquer pour ne prendre que ce qui m'est utile. Cela demande plus de temps mais cela permet d'apprendre. C'est comme ça qu'on apprend de nouvelles techniques de programmation ou qu'on peut comprendre l'utilisation de SDK complexes.
Par exemple récemment j'ai intégré une bibliothèque swift pour lire des .zip en enlevant les couches qui ne me plaisaient pas.
J'avais déjà intégré plusieurs fois des bibliothèques .zip dans le passé sans les comprendre et c'était globalement ok, même si j'ai eu des problèmes avec l'encodage des caractères des chemins pour les apps qui sont distribués mondialement.
Mais cette fois-ci j'ai voulu bien comprendre car c'est une sur-couche du framework compression d'Apple.
Je ne regrette pas le temps passé car j'ai appris comme sont constitués les fichiers zip (la partie catalogue par la partie algorithme de compression).
Moi non plus. Puis j'ai commencé à broder autour d'URLRequest, et quand j'ai voulu regrouper les différentes fonctions dans une bibliothèque, je me suis rendu compte que ce que j'avais écrit se trouvait presque en intégralité dans AlamoFire (d'un point de vue fonctionnel). J'en suis au point où je me demande s'il ne serait pas mieux que j'élimine mon code au profit d'AlamoFire, qui est forcément plus éprouvé que le mien, et ça fera moins de code à maintenir.
Par rapport au travail en équipe: si on parle d'un truc aussi répandu qu'AlamoFire, il y a des chances que les nouveaux aient déjà eu un contact avec cette librairie, et c'est ça en moins qu'ils devront apprendre.
Quant au "cherry-picking" dans les librairies open-source: s'il ne s'agit que de dupliquer un nombre très limité de fonctions, rien à dire évidemment. Mais après dès que ça se développe, ça devient vite un bordel pour mettre à jour les éléments qu'on a repris ailleurs. Passé un certain stade, il y a moins de risques à utiliser une librairie open-source en entier que chercher à isoler les éléments (et j'ai de toute façon l'impression que les grosses librairies sont passées de mode).