Tutorial sur l'Objective-c
devulder
Membre
Bonjour,
Un site (en anglais) avec des tutoriaux pour apprendre l'Objective-c
J'aime bien le style des pages.
http://rypress.com/tutorials/objective-c/index.html
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Regardé vite fait, ça a l'air sympa.
Sinon, j'ai pas aimé le fait qu'il y ait une partie sur du try/catch, j'ai horreur de ça.
Et j'ai trouvé dommage qu'on ne parle pas plus que ça des CFRelease et assimilés... Car même l'ARC ne les désalloue pas, il me semble.
Tres sympa, un bon tour de ce qu'il faut savoir pour commencer. Je garde!
J'avoue c'est sympa comme site, tout mignon en plus avec ses petites icônes !
C'est quoi le problème avec @try @catch ? Pas sérieux ? Facilité ? Ou c'est juste une affaire de goût? @try m'a permis de traiter dans une seule routine tous les cas extrêmes d'un arrayController (pas encore awake, contenu pas encore fetché, array encore vide, etc...)
Affaire de goût. Je ne trouve pas ça propre. Pour du débug, je ne dis pas non. Mais dans une version finale sans C++ (par exemple), je dis non.
Laisser dans un tutorial de base les try/catch, je trouve que ça incite le débutant à les utiliser.
C'est vrai que la gestion par exception est moins répandue dans la communauté Cocoa mais cela reste un outil puissant qu'il serait dommage de diaboliser Larme.
J'ai trouvé l'article sur ce sujet d'ailleurs plutôt bien réalisé. Il n'y a qu'une chose sur laquelle je ne suis pas tout à fait d'accord avec l'auteur:
Cela sous entend qu'on a systématiquement affaire à un bug non géré par le programmeur. Hors l'usage des exceptions peut tout à fait être une philosophie de codage. On le voit par exemple dans d'autres langages comme Java où son usage est beaucoup plus répandu.
A mon sens, l'utilisation des exceptions à l'avantage de grandement alléger le code et là où une gestion d'erreur mal calculée peut être fatale, la gestion d'exception offre une sécurité complémentaire non négligeable: celle de pouvoir attraper au vol toute erreur même non anticipée (ce qui est notre cas d'usage le plus courant en Cocoa).
Un débordement de NSArray peut effectivement être considéré comme un "manque d'anticipation" du développeur (je trouve aussi que c'est donc pas forcément un bon exemple à donner en terme d'usage) mais si on prend par exemple le traitement d'un flux de données comme du XML où on sait jamais trop à quoi s'attendre venant d'un serveur Web. Une petite encapsulation du parsing dans un try/catch est pas forcément du luxe.
Bah, c'est une querelle de puristes, comme:
- l'encapsulation qui, pour des classes non-réutilisables, frise la schizophrénie ("je me cache à moi-même des propriétés que j'ai définies");
- la gestion manuelle de la mémoire (je n'ai pas trop confiance en ARC et j'aime jouer au petit dieu avec mes objets);
- l'usage ou non de l'AppDelegate comme carrefour des IBOutlets;
- le IF (self) après un appel à une classe de Foundation (dès fois que NSView retournerait NIL)...
Moi, je suis pour l'éradication du ELSE et du DEFAULT:BREAK; qui dénotent un certain laisser-aller... ^_^
Moi j'aime bien gérer manuellement ma mémoire. Ne m'enlève pas ce plaisir!
Plus sérieusement, il faut aussi admettre que bien souvent une nouvelle technologie prise trop à bras le corps sans recule peut amener à un usage abusif. Et c'est souvent ce qui va se passer avec un débutant. On en arrive très rapidement à des aberrations comme de lire qu'avec ARC plus de problèmes mémoire (même pas on s'en préoccupe, c'est le bidule qui gère) ou bien encore que la gestion par exception est "THE" solution à la gestion d'erreur. -en cela d'ailleurs l'article du tutoriel est plutôt bien rédigé, c'est juste l'exemple qui pour rester simpliste prend un cas d'école critiquable-
Il ne faut pas non plus oublier que pour certains d'entre nous c'est notre métier de longue date. De là à développer des toc compulsifs, basés sur l'expérience de la perte de quelques kilos suite à des situations de stress intense en production, il n'y a qu'un pas que la médecine n'a pas encore réussi à soigner mais elle y travaille. :P
-Mmm, où sont passées mes petites pilules rose à moi!?!- ;D
J'avoue avoir passé quelques nuits blanches il y a bien des années avant la démo devant les clients. Je n'aimerais pas revivre ça et je suis content d'avoir affaire à un public plutôt bienveillant (il est vrai aussi que mes apps leur sont fournies gratuitement).
J'ai découvert les TRY avec Applescript, où il était difficile de prévoir tous les cas de figure durant le pilotage d'applications. J'ignorais leur existence dans Xcode jusqu'à il y a quelques jours.
Cela m'a permis de me dégager un peu la tête en bossant avec Core Data, les Prepare Contents, les fetch predicates et la sale habitude qu'il a de différer certaines opérations. Alors, plutôt qu'un "if ([myController content])" (qui dénote aussi une programmation hésitante et méfiante) je flanque mes opérations d'affichage dans un TRY en sachant que souvent, quelques microsecondes plus tard, une ligne de code qui ferait se planter le programme sera effectuée normalement.
C'est tout. Sinon, tous les IF, tous les CASE, tous les TRY du monde n'empêcheront pas le lambda user de mettre à jour une situation imprévue.
"Comment ça, tu as posé ton livre sur le clavier?!" ???