Objective-C comparé à Swift en 2020

Cette discussion a été créée à partir de réponses séparées de : Interagir avec un objet Cocoa par la programmation.

Réponses

  • newMCNconnecteur.texteChamp.stringValue = @"mon texte"; devait faire l'affaire!

    Ca fait bizarre de revoir du code Objc étant passer sous Swift ;)

  • DrakenDraken Membre
    novembre 2020 modifié #3

    @devulder a dit :

    Ca fait bizarre de revoir du code Objc étant passer sous Swift ;)

    Très bizarre, même ! C'est comme regarder le premier Jurassic Park !

  • Joanna CarterJoanna Carter Membre, Modérateur
    novembre 2020 modifié #4

    @MortyMars a dit :
    En deux mots les avantages de Swift par rapport à Objc ?

    Le bonheur B)

  • @Joanna Carter a dit :

    @MortyMars a dit :
    En deux mots les avantages de Swift par rapport à Objc ?

    Le bonheur B)

    Le compte est bon 😉🤓

  • CéroceCéroce Membre, Modérateur

    @MortyMars a dit :
    En deux mots les avantages de Swift par rapport à Objc ?

    • Plus expressif.

    Les inconvénients:

    • complexe
    • très lent à compiler.

    Mais de toute façon, Swift a cinq ans et les nouvelles API d'Apple (exemple: SwiftUI et Combine) ne sont disponibles qu'en Swift. Alors c'est un non-choix.
    ObjC ne se justifie guère que pour s'interfacer à d'autres langages: C++ mais aussi les langages de scripts.

  • @Céroce a dit :

    • complexe

    Non. Ou alors étaye un peu 😉

  • CéroceCéroce Membre, Modérateur

    Non, je n'étaye pas.
    Je n'ai pas d'exemple faisant intervenir génériques, protocoles et collections sous la main. B)

  • LarmeLarme Membre
    novembre 2020 modifié #9

    L'énorme avantage d'Objective-C par rapport à Swift était sa stabilité...
    ABI règle ça normalement dorénavant, mais il en aura fallu du temps.

    En bref, un même code écrit en Objective-C pouvait compiler sans soucis maintenant ou il y a 5 ans. En Swift, avec l'évolution du langage, pas vraiment. Et ça pose un soucis, car la version Swift était plus ou moins liée à une version d'Xcode qui était plus ou moins liée à une version de macOS.
    En bref, imagine devoir ressortir du vieux code, rajouter un fix de 3 lignes, genre un "if", pour le compiler (et donc livrer ensuite), c'est une galère sans nom : le code ne compile plus, ton Xcode actuel ne gère plus cette version de Swift, mais ton macOS ne gère pas la version Xcode qui gère cette version de Swift, ou la minimum la version d'Xcode suivante qui permettrait d'utiliser le Wizards et de passer ton code à Swift n+1, ou n.m+1

  • Le seul truc chiant a mon sens sur Swift c'est que votre programme utilise
    un framework externe il faut le recompiler avec la version actuel de swift.
    Sinon c'est tip top 😛

  • Il est incroyablement facile de créer des interfaces graphiques avec SwiftUI. Rien que ceci justifie le changement de langage.

  • @Draken a dit :
    Il est incroyablement facile de créer des interfaces graphiques avec SwiftUI. Rien que ceci justifie le changement de langage.

    Exact,
    Quelques exemples simple mais sympa ici: https://github.com/jordansinger/slack-macos-swiftui-sample

  • @Céroce a dit :
    Non, je n'étaye pas.
    Je n'ai pas d'exemple faisant intervenir génériques, protocoles et collections sous la main. B)

    Ah tu voulais dire moderne ! 😉

  • CéroceCéroce Membre, Modérateur
    novembre 2020 modifié #14

    @Pyroh a dit :

    @Céroce a dit :

    Ah tu voulais dire moderne ! 😉

    Ah non, pour avoir du code Swift moderne, il faut créer son propre DSL à base de @propertyWrapper, de callAsFunction, et évidemment définir ses propres opérateurs. Le reste est so 2017.

  • @Céroce a dit :

    @Pyroh a dit :

    @Céroce a dit :

    Ah tu voulais dire moderne ! 😉

    Ah non, pour avoir du code Swift moderne, il faut créer son propre DSL à base de @propertyWrapper, de callAsFunction, et évidemment définir ses propres opérateurs. Le reste est so 2017.

    Ouais là je suis d'accord avec toi 😅. Sauf pour le DSL c'est pas un @propertyWrapper qu'on utilise mais un @_functionBuilder (officialisé en @resultBuilder bientôt dispo dans Swift 5.4...).

  • @Pyroh a dit :

    Ouais là je suis d'accord avec toi 😅. Sauf pour le DSL c'est pas un @propertyWrapper qu'on utilise mais un @_functionBuilder (officialisé en @resultBuilder bientôt dispo dans Swift 5.4...).

    Ton LSD tu le coupes avec de l'acide acétique à 12%, ou avec du talc ? (je demande pour un ami..)

  • @Draken a dit :

    @Pyroh a dit :

    Ouais là je suis d'accord avec toi 😅. Sauf pour le DSL c'est pas un @propertyWrapper qu'on utilise mais un @_functionBuilder (officialisé en @resultBuilder bientôt dispo dans Swift 5.4...).

    Ton LSD tu le coupes avec de l'acide acétique à 12%, ou avec du talc ? (je demande pour un ami..)

    J'ai l'air de quelqu'un qui coupe son LSD ? :wink:

  • @Pyroh a dit :

    J'ai l'air de quelqu'un qui coupe son LSD ? :wink:

    Un vrai puriste 👍

  • Joanna CarterJoanna Carter Membre, Modérateur
    novembre 2020 modifié #19

    Pour déclarer la classe ObjC

    // ObjcClass.h
    
    @interface ObjcClass : NSObject
    
    @property (strong, nonatomic) NSString *name;
    
    @end
    
    // ObjcClass.m
    
    #import "ObjcClass.h"
    
    @implementation ObjcClass
    
    @end
    

    Pour l'appeler de ObjC

    void test()
    {
      ObjcClass *obj = [ObjcClass init];
    
      obj.name = "Joanna";
    }
    

    Pour l'appeler de Swift

    func test()
    {
      let obj = ObjcClass()
    
      obj.name = "Joanna"
    }
    
  • @Joanna Carter a dit :

      ObjcClass *obj = [ObjcClass init];
    

    Tu ne fais pas d'alloc ? Et du coup, plutôt faire new?

  • Joanna CarterJoanna Carter Membre, Modérateur

    @Larme a dit :
    Tu ne fais pas d'alloc ? Et du coup, plutôt faire new?

    Oops ! Faute de mémoire ;)

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