Protocol implémenté par une classe et une structure

2»

Réponses

  • Joanna CarterJoanna Carter Membre, Modérateur
    février 2017 modifié #32


    Je te présente mes excuses, c'est une erreur de vocabulaire de mon côté. o:)




     


    Mon fils, tes péchés te sont pardonnés  ;)


     




    Ah bon ? Tu peux m'en dire plus ? ???




     


    Je fais les frameworks depuis presque 20 ans, en plusieurs langages (Delphi, C#, Objective-C et Swift) et chaque langages apporte ses caprices et ses bizarreries. Côté développement iOS.


     


    C'est souvent le cas, qu'on veuille amasser n'importe plusieurs types qui soutiennent le même protocol dans une liste ou un dictionnaire.


     


    Objective-C est un langage dynamique mais qui n'avait, jusqu'à  récemment, les types génériques ; du coup, il fallait beaucoup de type-casting pour mettre les objets dans les listes ou les dictionnaires et, en plus, NSArray n'accepte que les objets qui derive de NSObject.


     


    Avec Swift, nous avons encore les soucis avec le protocols "génériques", dont on ne peut pas faire les listes à  cause de ses paramètres "associatedtype" et ses références à  Self ; pour ça il faut s'embrouiller dans le monde de "type erasure"  :/   Et on manque l'introspection ; ce qui est très utile pour manipuler les types pas encore connus, comme on trouve dans la lecture de JSON, etc.


     


    J'ai déjà  fait les exercices en telle programmation ; par rapport à  C#, c'était pas jolie  :(


     




    Mais je n'ai jamais dit que ta solution était pourrit !




     


    Et je n'ai pas pensé que tu en a dit  :)


     




    Je dis simplement que si le protocol Copyable dépendait de CopyInitialisable, on éviterait des oublies mais comme tu l'as mentionné, nous serions obligé de de créer la méthode init(_: Self) dans les structures qui en dépendent même si ça ne sert à  rien.  ::)




     


    Et c'est la bonne analyse des affaires comme ci qui fait la différence entre les bons et les mauvais développeurs ; ceci dit, l'apprentissage n'est pas facile sans quelqu'un(e) expérimenté(e) pour s'aider. C'est pourquoi nous pouvons profiter de l'entraide fourni par ces discussions ici au CocoaCafé 



  • Et c'est la bonne analyse des affaires comme ci qui fait la différence entre les bons et les mauvais développeurs ; ceci dit, l'apprentissage n'est pas facile sans quelqu'un(e) expérimenté(e) pour s'aider. C'est pourquoi nous pouvons profiter de l'entraide fourni par ces discussions ici au CocoaCafé 



     


    Bon là  on s'écarte vraiment du sujet initial. ^_^


     


    Je ne crois pas que nous parlions de bon ou de mauvais développeurs mais de point de vue qui s'opposent.

Connectez-vous ou Inscrivez-vous pour répondre.