groumly a écrit 3302 commentaires

Faut peut être se calmer un peu la, on est très loin du « c’est une pute, un rabin et un noir dans un ascenseur » quand même.

La blague initial ne se moque pas des non binaires, c’est juste une association absurde entre la non binarité des genres et la binarité des booléens. Le suivi étant juste la blague vieille comme le monde sur dix/deux en binaire.

Renvoyer un optionnel, par exemple, va m'empêcher de chaîner les appels, et va me forcer à écrire beaucoup de boilerplate moche, à moins de n'avoir que des optionnels partout (bonjour la complexité pour vérifier chaque optionnel au début de chaque fonction, sans compter l'impact sur les perfs).

Heu, ouais, mais si t’as pas d’élément le plus grand, il va bien falloir gérer ça quelque part quand même. Soit tu gères ça au call site (voir le call site du call site), soit tu laisses ça remonter en mode « quelqu’un d’autre peut pas l’faire?!? ».

Dans le premier cas, t’es pas dans une semantique d’exception, mais de gestion de code d’erreur. Le compilateur peut t’aider si le langage a un support avancé de ce genre de choses, mais au final, la problématique est surtout « cosmétique »: comment écrire le code de facon concise et lisible. Utiliser des exceptions parce que ça te permet de try/catcher au call site plutôt qu’un if return, c’est un peu bourrin. Et surtout, ça va pas fondamentalement résoudre le problème si le call site risque de se prendre plus d’une exception. Même topo si tes call stacks sont très profondes: t’as un très probablement un problème architectural. Si tu viens me dire qu’un if/return est trop cher, ma réponse va être: j’en doute, en tout cas pas sans un benchmark sérieux montrant un impact concret (pas un benchmark qui cherry pick « 50% mieux », en omettant de dire que les 50% mieux, c’est 2ms, ou 0.1% du temps d’exécution total).

Dans le deuxième cas, c’est très précisément ce qu’il ne faut PAS faire avec des exceptions. Les laisser remonter dans une couche qui n’est même pas au courant que les couches inférieures existent.

Comme tu dit, les exceptions doivent être exceptionnelles. Ne pas trouver un élément dans une collection n’est pas exceptionel, c’est attendu, et ça doit absolument être géré au call site. Pour être tout à fait honnête, pour du code métier, c’est très dur de trouver un exemple ou les exceptions sont justifiées. Ton code métier, il a des cas d’erreurs, et ils sont spécifiés clairement (ou devraient l’être, à l’ingénieur de bosser avec ses stakeholder quand il en découvre). Les erreurs techniques, dans leur immense majorité, elles sont plutôt predictibles, et se ramènent très souvent à une erreur métier. Ta db est en carafe? Est ce que c’est si différent que ne pas trouver ton élément? Probablement pas.
Ton dao/repository/whathaveyou, lui va probablement vouloir faire la différence entre « pas trouvé » et « bestel il a pété la db et elle a fait pfft », pour ton logging/monitoring notamment. Mais la encore, y’a des façons beaucoup plus élégante de représenter ca. Tu reçoit soit le résultat, soit une erreur. Ça se modèle très bien avec un tuple, et des enums vont rendre le code de gestions d’erreur beaucoup plus simple à écrire parce que ca se découvre tout seul.

Je ne mettrais pas plus de disque dans un cas exceptionel non plus. Les I/O ça peut foirer pour un paquet de raisons tout à fait légitimes et courantes. Idem pour le réseau. C’est pas vraiment un cas exceptionel, et si le call site par du principe que l’io va passer, ben le code est très fondamentalement buggé (et a probablement des problèmes plus gros que de savoir s’il faut lancer une exception).

Plus de ram, je mettrais ça effectivement dans une exception. Essentiellement parce que si t’as plus de ram, c’est potentiellement très difficile de s’en sortir, vu que tu risques d’avoir besoin de ram pour libérer de la ram. Disons que c’est un peu la branche sur laquelle t’es assise, si elle pete, ça devient tout de suis plus compliqué.

Bref, de mon point de vue, les exceptions posent 2 gros problèmes:
- perte complète du flow de contrôle ou tu vas de la à de la d’un coup sans crier gare
- problèmes des performance lié au stack unwinding etc

Le deuxième point s’applique surtout à des très gros projets, donc rarement pertinent pour le commun des mortels. Ça se mitige bien si le compilateur transforme le type de retour pour un tuple (typeDeRetour, Erreur) de façon transparente, et ajoute le sucre syntaxique à la volée. Genre ce que fait swift. Bon courage pour introduire ça en c++ par contre, le train a quitté la gare, comme on dit outre quebin.

Le premier, ça devient plus compliqué. Déjà, les unchecked exceptions, c’est vraiment de la merde. Ça sort de nul part et paf, pastèque. Forcer à les déclarer aide. Forcer un try léger au call site aide aussi. Ça évite de faire un appel qui peut lancer, et le rater parce que ta signature inclue l’erreur lancée.

Alors, certes, ta fonction peut aussi lancer, et celle qui l’appelle aussi, sur 50 niveaux, retour à la case départ, on a un goto déguisé. Pour être tout à fait honnête, si tes exceptions bubblent sur plus de 2 niveaux, t’as un très très très gros problème de leaky abstraction. Les couches ne sont pas isolées du tout si tu peux remonter plus de 2 niveaux. Et ça, c’est un bien plus gros problème que de savoir si les exceptions sont autorisees ou pas.

ça nous laisse avec des cas réellement exceptionnels, qui se comptent sur les doigts d’une main. Genre « on a plus de ram » ou « un des core du cpu a disparu à la volée » et autres cas tarabiscotés du genre. J’ai pas de réponse pour ce cas là. Mais disons que c’est très très très loin d’être courant, et si ce genre de gestion représente plus de 0.00001% du code écrit, je serais surprit. Je serais déjà surprit si ne serait ce que 1% des projets gèrent ce genre de problèmes.

Bref, au final, c’est un faux débat. Le concept même de l’exception (une erreur opaque que tu rebalance au niveau supérieur) est plutôt un anti pattern, et se gère beaucoup mieux avec un type result, ou un tuple syntaxique. Et vu le pot de pus que sont les exceptions en c++, je trouve pas ça délirant de les interdire.

« Pas toujours vraiment de travail de composition » est probablement plus correct :)

Recopier la partition c'est une chose. La deviner à l'écoute s'en est une autre.

Je doute que la façon de reproduire ait une quelconque incidence sur le fait que ça soit une contrefaçon. Si je fait une copie à la main d’un album de Gaston Lagaffe, plutôt que de le photocopier, ça reste une contrefaçon.

Dans l’ensemble, je suis d’accord que beaucoup de partitions vont être des contrefaçons. OLGA à du fermer à cause de ça. Mais ils donnaient des partitions exactes d’œuvres, avec les riffs, les solos, et la tablature complète qui collait à la chanson. La composition complète était reproduite (et oui, la composition écrite est une œuvre).

La ou je voit du flou, c’est sur un milieu comme le jazz (ou le blues), ou il n’y a pas vraiment de travail de composition. Les mecs partent sur une grille d’accord qui est dérivée d’une gamme, qui est elle même dérivée d’une sous division précises des fréquences audio + une note de départ, et partir de la, c’est 99% de l’interprétation. Ces sous divisions ont été choisi y’a des siècles, et ont tendance à être stable à travers différentes culture. Je cherche pas à diminuer le travail/talent, mais dans l’ensemble, les progression d’accords, c’est un truc un peu mécanique, pas vraiment créatif.

Pour faire un parallèle (probablement douteux), imagine que je mette en place en site d’inspiration pour les DM de jeu de rôles. Et que dedans, j’ai des trucs du genre « le seigneur des anneaux: un mec plutôt pas très grand reçoit la visite d’un magicien, et se met en tête de jeter un anneau dans un volcan, récupérant quelques potes en chemin ». J’ai clairement pas commit une infraction au droit d’auteur. C’est un peu du même tonneau ici.

Ok pour les paroles, ça c’est clairement couvert et pas ambigu du tout. Miles Davis ne chante pas, donc j’avais pas de paroles sur celles que j’ai regardé :)

Le plan de missile est un plan très détaillé de la centrale, et le suivre te donnera exactement le meme missile.

Pour le jazz, c’est plutot différent. Les mecs ne jouent pas « un morceau ». Ils jouent leur inspiration du moment d’une progression d’accord. Le concept de composition devient plutôt flou quand la composition se limite à « une demi douzaine d’accords choisi parmi 2 douzaines, suivant les règles usuelles de gamme etc ».

Ça me parait beaucoup plus difficile de protéger quelque chose d’aussi abstrait et sujet à 99% à interprétation. A ce compte la, je peux protéger 100% des créations musicales a venir en générant toutes les variations raisonnablement écoutables de 12 mesures (y’en a pas tant que ça au final). Ce qui ne parait pas être l’esprit de la loi en la matière.

Bref, j’irais pas parier mon déjeuner dessus, mais quand je voit all blues, je suis pas convaincu qu’un juge enverra Jean Michel en prison pour contrefaçon.

Je suis pas avocat, et je sais pas lire une partition. Par contre, j’ai des oreilles, un peu de jugeote, et quelques albums de jazz.

Quand je voit sa partoche d’all blues, il a 12 mesures et la grille d’accords qui va avec. Le morceau de miles davis fait 11 minutes, et bon, c’est pas comme si le père miles jouait le même couplet/refrain en boucle pendant 11 minutes. Sa partition est clairement pas une transcription fidèle du morceau

Vu le milieu, je suis même pas convaincu qu’il y’ait une composition formelle à la base, sorti de « tant que ça colle à peu près sur la si do re mi, c’est toi qui voit comme tu le sens ». Même si je pense que t’as plutôt raison dans l’absolu, je suis pas convaincu que l’ayant droit puisse dire qu’il est interdit de poster ces 12 accords. Ça serait la partition complète du morceau tel qu’enregistre sur kind of blue, je dit pas, mais la je serais pas surpris si ça passe vu que tu peux vraiment pas faire grand chose avec cette partoche sans avoir beaucoup d’expérience à jouer du jazz.

Faut voir ça comme une opportunité, pas un problème. Ca donne une certaine latitude à l’implémentation.

Vu qu’il est grosso modo garantit d’être 7h00 dans une timezone dans moins d’une heure (peut être même 30 minutes!), il suffit d’exécuter la tâche un 31 juillet, à l’heure pile, et paf, ça reste correct!

Honnêtement, tu craques complètement la dessus.

Tous les pointeurs sont super doués! 💪

Je trouve que prendre tous ces gens qui ont largement contribué à la plateforme de haut en leur disant que leurs usages "bof OSEF lol" est un manque de respect total.

Il dit pas osef, lol. Il dit que des classes clairement annoncées comme ne faisant pas partie du standard avec 0 garanties de maintenance ne peuvent pas être utilisée comme exemple de cassage d’api/abi. Tout comme je peux pas dire “le c++ casse les apis parce que qt a pété pleins de trucs avec le passage à qt5”.

Idem pour les enums.

C’est ce que je me disais. Tout recompiler à chaque fois, ça resoud des problèmes, mais ça en introduit d’autres aussi. Et surtout, ça devient très compliqué pour ceux qui ne font pas l’open source.

Je veux bien croire que ça marche très bien pour le marché de go, mais ça n’en fait pas une solution universelle.

Non, python va compter le même nombre de méthodes que tu soit dans l’objet ou à l’extérieur.

C++ voit ici une taille d’objet différent en fonction de si tu es dans la lib ou au call site.

t’as des exemples concrets? Dans l’ensemble pour peter une abi en java, faut vraiment se lever tôt et faire des trucs très très bizarres. Le bytecode a un peu été conçu pour ça, et sun/oracle ont toujours refusé d’y toucher (ce qui donne des conneries genre un Integer boxé en int qui te pete une npe, parce que c’est juste du sucre syntaxique).

Oracle s’est même retrouvé bloqué après avoir spécifié leur algo de hash pour les hashmap, ce qui leur a causé des soucis avec des DoS à cause de collisions dans les requêtes http. ckyl avait expliqué en long en large et en travers le problème ici même. Ils tiennent la route avec leur api publique.

Les changement d’api/deprecation arrivent, mais dans l’ensemble, à moins d’aller taper dans les classes “privées”, ça continue à tourner. Après, oui, c’est facile de se tirer une balle dans la jambe et se peter une runtime exception avec des jars qui ne sont pas les bons, mais ça c’est plutôt un problème de gestion de dépendances touffu qu’un problème de compat abi/api.

Oui, c’est ce que j’impliquais par “tant que ça pete pas en vol non plus”. C’est juste que c’est long et chiant a expliquer, mais comme tu l’as fait, j’ai pas à le faire :)

Et sinon, rien à voir avec la choucroute, mais vendor, ca veut dire fournisseur, pas vendeur.

Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?

Oui, tant que ça pete pas en vol non plus. Java est abi compatible aussi, un .class de 1993 tournera sans problème dans une appli écrite en 2022 en java 17 sans rien toucher.

Java (et actes associés donc kotlin aussi), swift/objc, c, .net aot ou jit, et un petit peu en c++ si tu plisses les yeux sont abi stable. Pas rust et go. Go essaye d’esquiver le problème en linkant tout en statique, mais je sais pas ce que ça donne en pratique pour la distribution de librairies?

Les languages de script ne sont pas distribués sous forme binaire, ce qui aide pas pour le b d’abi, donc le problème ne se pose pas pour eux.

Après pour ce qui est de l'ABI, est-ce vraiment une mauvaise chose que de vouloir éviter de casser l'existant ?

De mon expérience avec Swift (0 compat abi jusqu’à la version 4 ou 5), c’est très très très chiant. Ça veut dire que toutes tes dépendances doivent être rebuilt au grand minimum à chaque update du compilo. Et même avec ça, ça veut dire que toute l’équipe doit updated son compilo en même temps. Ce qui est compliqué sur un projet distribué. Ou alors tu passes ton temps à tout recompiler à chaque build, ce qui devient très vite chiant au quotidien, à plus forte raison en c++ vu les temps de builds. Ça a aussi vite fait de complexifier les builds CI et bouffer du temps pour pas grand chose. Surtout vu le merdier que sont les build tools en c++.

Dans le cas de Swift, l’effet c’est que très peu de projets sérieux se lançaient dans un framework en Swift. Une fois qu’Apple a déclaré l’abi stable, ça a ouvert les vannes.

On a beau aimer l’open source, le fait est que distribuer des binaires prebuilt est quand même plutôt pratique, au minimum, et obligatoire pour du code closed source, au pire. De ce que j’en voit, sortis de languages récents et relativement peu répandu, une abi stable est un peu la base de la base. Peter l’abi d’un coup me parait être un gros problème.

Les raisons de Google me paraissent plutôt justifiées. C++ était déjà un monstre de complexité y’a 20 ans. Ça n’a fait qu’empirer depuis. Vu leurs objectifs, ça me paraît raisonnable de faire ce qu’Apple à fait avec swift et objc: créer un language next gen de remplacement, en incorporant des ponts du nouveau vers l’ancien pour permettre une longue transition en douceur.

Je suis pas journaliste, donc à prendre avec des pincettes.

Mais se battre sur l’aspect quantitatif quand t’as en face google News ou Twitter, ça me parait être une bataille perdue d’avance si tu veux pas faire du putaclic. A plus forte raison quand ton public est assez prône à utiliser des bloqueurs de pubs.

Se concentrer sur ses abonnement et la qualité me parait pas forcément délirant.

Je suis resté calme. Et en l’occurrence, c’est parce que c’est pas sa première offense. Et 60% de ce qu’il dit n’a absolument aucun sens, et n’est explicable que par de la mauvaise foi crasse ou une méconnaissance abyssale des acteurs.

Le pire c’est qu’il a pas forcément tord sur les 40% qui reste. On parle d’un acteur qui a construit plus d’un milliard de téléphones, donc les jugements à l’emporte pièce, ca va quoi.

Et on peut pas vraiment dire qu’il ait prit un ton neutre/objectif en parlant de pomme non plus. Donc, oui, je maintiens mon qualificatif de clown et d’âneries (et je tire mon chapeau à pbpg au passage pour ceux qui ont remarqué la référence).

Je suis vraiment confus. Soit tu mens comme un arracheur de dents, soit t’es vraiment stupide. Surtout que c’est pas la première fois que je me prend la tête avec toi sur ce sujet.

Apple ont déjà, dans le passé, changé de connectique. Le fait que ça arrive à nouveau ne surprendra aucun utilisateur, ou alors seulement ceux qui ont la mémoire très courte.

Oui, ils l’ont déjà fait. La grosse différence est qu’Apple a vendu autant de téléphones cette année que ce qu’ils avaient vendu de téléphone en tout au moment de cette transition. Dit autrement, le parc existant fait pas loin d’un milliard de téléphone. Avec des cycles de renouvellement beaucoup plus long (le matos est arrivé à maturité depuis 2-3 ans), et avec un marché complètement saturé (a savoir, en 2012, une grosse part des ventes étaient le premier smartphone de l’acheteur, maintenant c’est du renouvellement). Si tu vois pas en quoi ça change complètement le problème, je sais vraiment pas quoi te dire.

Choisir Apple, ce n'est pas un choix de pérennité de la connectique

Avec plus d’un milliard de devices vendus, je pense qu’on peut dire sans trop s’avancer que Lightning ne va pas disparaître comme ça. Y’a des câbles de partout, des adaptateurs de partout. Les câbles officiels viennent en usb, et pour l’instant, apple est le seul constructeur de téléphone à avoir tenu plus de 10 ans sans changer de connectique. Donc tu repasseras.

tandis que l'intégralité des autres fabricants n'ont changé que pour passer à une connectique unique, la même pour tous, l'USB-C.

Ben voyons. La raison pour laquelle l’Europe bosse sur cette histoire depuis 2009, c’est précisément parce que les constructeurs de téléphone sortaient une nouvelle connectique par téléphone. Parfois du mini usb, parfois du micro usb. Si ce que tu dit c’est “les autres ont pas changé de connectique depuis la dernière fois qu’ils ont changé de connectique, forcément, on va pas être d’accord.

Racheter du matériel, ce n'est à l'évidence pas un problème pour les gens qui compte mettre un bras dans un téléphone Apple.

Ben voyons. Apple fait du milieu de gamme aussi. Un SE fait presque un tiers du prix d’un Samsung haut de gamme, et presque 30% de moins qu’un pixel 6a. Apple occupe les meme segments de marché que les autres gros constructeurs android.

combien de temps ils auraient tenu encore ?

Probablement pas si longtemps que ca, la situation devient dure à tenir pour eux. L’Europe les précipite probablement un peu plus qu’ils auraient voulu, mais dans l’ensemble, ils ont de l’usb c partout (laptop, ipad a part le bas de gamme, chargeurs, écran). Sauf sur l’iPhone, ce qui commence à faire chier les gens investis dans leur eco système. Ils sont clairement très investis dans l’usb c, leurs laptops sont usb c only depuis 2015, leur écran a 1500 boules à meme pas un connecteur usb a.

Leur business de license pour le Lightning leur rapporte probablement autant que ce que leur coûte l’overhead d’ingénierie, supply chain, et ligne de production séparées pour le Lightning. Et surtout, c’est une goutte d’eau dans leur chiffre d’affaire. Un seul Mac leur rapporte bien plus que des centaines de câbles, donc je doute que ça soit une histoire de gros sous.
Et ils vendront toujours des câbles usb à droite à gauche, donc c’est pas comme si cette partie de leur business allait disparaître.

Le gros problème pour eux, c’est la transition. Ça va prendre des années pour mettre à jour ne serait ce que 75% de leur parc. Et 25% du parc iPhone, c’est des dizaines/centaines de millions de personnes.

Leurs clients les plus fidèles, ceux avec plusieurs iPhones dans la famille, vont être emmerdés pendant des années avec ça. La transition iPod 30 pins a déjà prit des années, et c’était en plein dans le boom ou t’avais au moins une bonne raison de considérer un nouveau téléphone chaque année. C’est plus le cas maintenant, et le parc existant est 10 fois plus gros, c’est exponentiellement pire.

Perso, j’en ai pour plus de 5 ans avant de me débarrasser de lightning (2 ans pour remplacer mon téléphone, puis encore 2 a 3 ans pour le changer à nouveau, et que madame récupère l’usb c, et après encore 2-3 ans pour que les petits recuperent l’usb c de madame).

Ça veut dire que la brique de chargement partagée par la famille doit maintenant avoir 2 câbles, et les changer en permanence. Pareil dans la voiture. Pareil quand tu passes chez ton pote et qu’il a l’autre câble. Faut racheter le câble de rab que t’as pour quand tu voyages. Tout ça multiplié par plus d’un demi milliard de personnes.

Tout ça va être perçu comme étant la faute d’Apple. Surtout quand tu vois des clowns comme Tanguy qui soit ne sait absolument pas de quoi il parle, soit ment effrontément. Ce qui est un gros problème pour eux, vu l’attention qu’ils portent à leur image.

Enfin je pense que c'est aussi un signal politique.

Je pense que c’est surtout ça. En pratique, cette loi ne va pas changer grand chose. Les téléphones vont toujours venir avec un câble, et les constructeurs arretent de fournir des chargeurs. Avant que l’Europe ait passé leur loi, donc l’impact sur l’environnement est déjà mitigé. Le monde android à finit par se standardiser sur un câble utilisable par le commun des mortels. Y’a tellement d’iPhone en circulation que le Lightning est un standard de fait. Trouver un câble Lightning est vraiment pas compliqué. Le problème quand t’es en galère c’est plutôt d’en trouver un qui a le bon usb de l’autre côté (c vs a).

Tenir tête aux géant du milieu est plutôt une bonne chose (et faut pas compter sur les us pour faire ça, donc il reste que l’Europe). Le calendrier est plutôt mal tombé, l’exemple de base de “les lois vont à l’encontre de l’innovation”. Apple avait besoin de se débarrasser du 30 pins en 2010-2011. Usb c était pas prêt avant 2014. 4 ans, c’est une éternité dans ce monde a cette époque. Il fallait qu’ils fassent quelque chose.

Rien de ceci n’est étonnant venant d’Apple. Ils sont ravis d’utiliser des connectiques standard quand elles existent et font ce dont ils ont besoin. Cf usb a, wifi, Bluetooth, FireWire, microsd. Ils sont toujours parmi les premiers à lancer un large déploiement de ces choses. Ils avancent agressivement sur des trucs genre virer les dvd, floppy etc. Ils ont aussi un historique de rester bloqué avec des tiers partis quand l’alternative est trop coûteuse (cf la saga Intel). S’ils l’ont pas fait avec Lightning, c’est qu’ils savaient très bien que ça prendrait des années avant d’avoir un standard utilisable.

Et après, l’Europe a mit des années avant d’agir.

donc bref, oui, c’est surtout une loi politique. Ça change rien en pratique. Mais ça aide à garder un contre pouvoir face à des boites qui ont des CA plus gros que le budget de pas mal de pays. Ce qui est pas un mal.

lol, "connecteur de niche", t'es au courant qu'apple a vendu grosso modo 1 milliards de telephones avec un port lightning? Note que je compte meme pas l'iPad la dedans… Y'en a quelques uns qui aimeraient bien avoir des niches comme ca.

C'est vraiment difficile de te prendre au sérieux quand tu sort des âneries pareilles.

Le Lightning est totalement isolé et représente un surcoût qui n'a que peu d’intérêt tactique pour Apple.

Le gros point pour le lightning c'est que par design, c'est vachement plus robuste que de l'usb c. coté connecteur, c'est juste un trou. Cote cable, c'est juste un bout de metal. Pas de zigwigwi qui dépasse dans le connecteur, pas de prise "creuse" cote cable.

La poussière de ta poche qui finit inévitablement dans ton connecteur est super facile a sortir sur un iPhone: un trombone et t'y vas comme un bourrin, c'est juste un trou. avec un connecteur usb c, c'est pas la meme.
C'est pas un probleme avec un iPad ou un laptop, vachement plus avec un telephone.

Bref, tout ca pour dire, lightning avait des avantages reels sur usb c, en plus d'être disponible bien avant qu'usb-c sorte.

mini-FireWire cables

😳
t'as quoi comme Mac pour toujours avoir du firewire? Ca fait bien 10 ans qu'ils ont laissé tomber le firewire.

Reste à espérer que le constructeur concerné ne va pas en profiter pour mettre deux connecteurs: un USB-C qui fonctionnerait uniquement pour le chargement (comme ça ils sont en ordre avec la décision de l'UE) et un Lightning pour toutes les fonctions qu'on attend de ce type d'interface.

Ca serait complètement con, et irait a l'opposé de leur philosophie d'apple sur tous les appareils.

Le fait que ca soit sérieusement abordé en dit long sur les genies qui discutent sur ce fil.

Ca se discute. iOS supporte une 20aine de devices la dernière fois que j’ai vérifié. Ajoute à ça les montres, les laptop/desktops et les Apple TV pour le sujet qui nous concerne ici (pas le pasteboard, mais l’intégration à travers toutes les plateformes).