›

[iSwift] ou [Obj-C to Swift] bidon ou pas bidon ?

GercofisGercofis Membre
mars 2018 modifié dans Objective-C, Swift, C, C++ #1

Tout est dan le sujet, pour info iSwift est sensé réaliser la translation ObjC -> Swift.
J'ai tout de même des doutes, bref j'attends vos commentaires... peut-être même des utilisateurs ?

Réponses

  • LarmeLarme Membre
    #2

    Le gros du code iOS, c'est d'appeler le SDK iOS.
    Il faut juste apprendre à lire de l'Objective-C, ce qui est certes déroutant, mais pas ultra compliqué si on fait du Swift déjà car au final les points difficiles sont : particularités du langage, mais une fois qu'on a compris l'équivalent c'est bon, et l'algorithmie derrière, mais c'est pareil quand on rentre dans le code de quelqu'un d'autre.

  • PyrohPyroh Membre
    #3

    Bidon.

  • Eric P.Eric P. Membre
    #4

    @Pyroh a dit :
    Bidon.

    Peux-tu développer ?
    As-tu testé ?

  • PyrohPyroh Membre
    #5

    Tu ne peux pas faire en Swift tout ce que tu fais en Obj-C et vice-versa. Une conversion automatique de l'un vers l'autre est donc rendue de facto bancale parce que le convertisseur devrait alors comprendre le sens du code et non pas simplement le convertir.
    Il faut ajouter à ça que du code Obj-C produira dans la plupart des cas un code Swift naïf qui ne colle pas à l'esprit de celui-ci et conséquemment produit du mauvais code.
    Donc en résumé si c'est pour du code simple autant le faire soi-même et apprendre à lire l'Obj-C ce qui n'est pas compliqué. Si c'est pour du code plus complexe il faut de toute façon le faire à la main.

    Et autre détail affreusement subjectif : tout développeur un tant soit peu sérieux vous dira que la conversion automatique de code est à proscrire.

    Après c'est vous qui voyez mais quand on code pour le plaisir on a le temps de se pencher sur l'Obj-C. Si on code de manière professionnelle on connait la valeur à long terme d'apprendre à lire l'Obj-C.

  • JérémyJérémy Membre
    #6

    @Pyroh a dit :
    Et autre détail affreusement subjectif : tout développeur un tant soit peu sérieux vous dira que la conversion automatique de code est à proscrire.

    +1 ;)

  • GercofisGercofis Membre
    #7

    Mais je connais Obj-C et Swift pas forcément super bien disons que je me débrouille ( sans plus ! ).
    Le prix n'est pas exorbitant non plus 15 € ..
    J'aurais souhaité la réponse d'un utilisateur.
    Je me doute bien que ça ne va pas être du top de chez top, sinon Apple l'aurait fait

  • Eric P.Eric P. Membre
    #8

    Merci Pyroh !

    La conversion d'une app en Objectice-C vers le Swift n'est pas un travail forcément très intéressant et si une bonne partie, pourquoi pas les plus simples, pouvait être automatisée...

  • PyrohPyroh Membre
    #9

    Bon si on prend rien que l'image qu'ils donnent en exemple ils convertissent

    #import <Cocoa/Cocoa.h>

@implementation aClass

- (void)aFunc(int: a) {
    NSString* s = @"Hi";
    NSArray* a = @[@"1", @"2"];
    NSString* i;
    for (i in a)
    {
        NSLog(@"i = %@", i);
    }
}

@end

    en

    import Cocoa

class aClass {

    func aFunc(a: Int) {
        var s: String = "Hi"
        var a: Array = ["1","2"]
        var i: String

        for i in a {
            NSLog("i = %@",i)
        }
    }

}

    Ce code est extrêmement dégueulasse et c'est le boulot de quelqu'un qui ne sait pas coder en Swift
    Un codeur aguerri aurait plutôt fait un truc de ce genre :

    // Cocoa est inutile ici
class aClass {
    func aFunc(a: Int) {
        // let plutot que var
        let s = "Hi" // Le type est induit
        let a = ["1","2"] // Pareil et au passage Array est generic donc pas sur que ça compile

        a.forEach { print("i = \($0)") }
    }
}

    Bref je ne conseille pas ce soft. Mais je ne vais pas vous empêcher de l'utiliser.

  • muqaddarmuqaddar Administrateur
    #10

    Je ne sais pas comment codent la plupart des swifteurs, mais j'aimerais bien voir le type écrit, plutôt qu'induit. Je trouve ça plus propre et rapide à comprendre à la relecture (imaginons qu'il y a 20 variables...)

  • klogklog Membre
    mars 2018 modifié #11

    Entièrement d'accord avec toi muqaddar : l'absence de type me parait moins propre et plus plantogène, particulièrement avec des noms de variables aussi peu signifiants.

    Quant à la boucle, je la trouve, là aussi, moins lisible. Je ne sais pas trop quel gain de temps cela représente d'écrire de manière aussi compacte. Par contre, je vois parfaitement combien cela pourra compliquer la reprise d'un code que l'on n’a pas écrit ou que l'on a oublié. Il y a sans doute des trucs qui m'échappe, mais franchement, "$0" est-il plus lisible que le "i" que l'on définit explicitement ?

  • FKDEVFKDEV Membre
    #12

    Moi aussi j'ai du mal avec les map et les forEach.
    C'est peut-être une question d'habitude.
    Ou alors c'est une mode qui va passer parce que cela n'apporte pas grand chose en fait.

  • MagiicMagiic Membre
    #13

    Dans la plupart des Guidelines qu'on trouve on a tendance à omettre le type d'une Variable pour une écriture simplifiée. Pour ma part la présence du type est importante que lorsque le type de la valeur est difficilement perceptible. Dans les exemples montrés ci-dessus il me paraît donc juste de ne pas les saisir, on voit tout de suite de quoi on parle.

    Quand à la boucle, c'est justement pour une question de lisibilité et de facilité à la programmation fonctionnelle. Si on développait davantage le tableau en appliquant des filtres, des changements de valeurs et/ou de types, il est bien plus facile de le faire avec une programmation fonctionnelle.

    Dans l'exemple montré donc, l'usage du forEach n'est pas forcément pertinent mais il n'est pas non plus déconseillé bien au contraire.

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