Literal Syntax for NSArray, NSDictionary & NSNumber
muqaddar
Administrateur
Tiens, je viens de tomber sur ce post.
Sympa tout ça !
Donc pour un dico:
NSDictionary *tweet = {
@site: @CocoaCafé.fr,
@admin: @muqaddar,
@timestamp: 1331664532
};
Sympa tout ça !
Donc pour un dico:
NSDictionary *tweet = {
@site: @CocoaCafé.fr,
@admin: @muqaddar,
@timestamp: 1331664532
};
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est pas sous NDA ?
Tu passes ton temps à faire de la veille techno ma parole !
En tout cas c'est super cool cette nouvelle notation !
Faudrait juste pas que ça devienne une habitude de vouloir tout simplifier non plus.
En même temps, ce que dit Zoc c'est écrit noir sur blanc dans le lien que tu donnes... /rolleyes.gif' class='bbc_emoticon' alt='::)' />
Oui et non /biggrin.png' class='bbc_emoticon' alt=':D' /> Je trouve ça pas mal pour simplifier les choses, mais je n'aime pas trop la façon dont c'est présenté. J'aime bien quand ce genre de truc restent assez discrets. Quand Apple a présenté ARC j'ai failli tomber dans les pommes (sans jeu de mot), tout simplement parce que ça incite les plus flemmards à se mettre à l'Objective-C sans rien capter de la gestion mémoire. Là on va se diriger vers quelque chose de similaire mais concernant la syntaxe même de l'objective-c, et c'est vrai que ça fait un peu peur, mais tout dépendra de la façon dont Apple présentera la chose (ou ne la présentera pas)
L'astuce est très jolie, je l'ai réimplémentée de mon côté pour corriger 2-3 trucs, testé, et approuvé !
Ainsi on peut par exemple écrire du coup :
Ca serait bien que l'ObjC accepte en standard cette construction de switch/case avec des NSObject (test sur "isEqual:") plutôt qu'avec juste des int comme le C, non ?
A vue d'oe“il je dirais une catégorie et une redirection dynamique de message pour avoir une gestion de case infinie... C'est donc la seconde partie qui joue avec le runtime.
Ce qui serait bien c'est les choix multiples du genre:
case 1,2,3:
case 1 to 10:
Et ce projet est open-source ? Un lien github à donner peut etre ? /smile.png' class='bbc_emoticon' alt=':)' />
C'est l'auteur, Nicolas Bouilleaud, qui a proposé sur la Mailing List CocoaHeads d'en parler lors d'une session aux CocoaHeads Paris, ce qui m'a fait chercher son projet et le découvrir.
@Louka : La manipulation du RunTime est simple, comme l'a deviné yoann, ça utilise la possibilité de "Dynamic Method Resolution" du Runtime Objective-C. En gros l'objet qui gère le switch n'implémente aucune méthode directement à la compilation, par contre au RunTime quand n'importe quelle méthode est appellée, le Runtime ne la trouvant pas va laisser une chance à l'objet de la résoudre dynamiquement, comme expliqué dans la doc Apple. C'est à ce moment là qu'on regarde si c'est bien une méthode de type "case::case::case::[...]default:" et qu'on la résoud à la volée.
PS : Par contre le seul inconvénient du Dynamic Method Resolution, c'est que lorsque l'on compile, le compilo nous met forcément un warning pour dire qu'il ne trouve pas la méthode "case::case::case::default:". Alors que bien sûr ça ne pose pas de problème puisqu'elle est résolue dynamiquement.
Si quelqu'un a une solution pour enlever ce warning ? J'ai essayé mais ça n'a pas l'air de suffire.
Cela a une réelle utilité au moins.
Hormis générer un protocole avec une vingtaine de déclaration de switch/case je crois qu'il n'y a pas de solution propre... Rien à ma connaissance pour dire au compilo "Cette classe est capable d'assumer tout et n'importe quoi".
C'est dommage de permettre plein de trucs intéressants sur la résolution dynamique de méthodes, genre resolveInstanceMethod et forwardInvocation, sans permettre de désactiver les warnings pour cette classe pour autant. Ca limite l'utilisation de ce genre de truc du coup. Même pas un attribut C99 __attribute((...)) ?
Avec LLVM ou GCC ?
Je demande ça car j'ai effectué quelques tests. GCC ne prend évidemment pas le pragma en considération, mais pour LLVM je n'ai aucun warning avec le pragma, alors qu'il sont effectivement présent lorsque ce dernier n'est pas présent.
Je me suis permis de forker ton projet pour en faire une version ARC et iOS5 uniquement (en utilisant NSJSONSerialization), et j'ai franchement une mauvaise nouvelle: Quand on utilise ARC, les warnings concernant les méthodes inconnues se transforment purement et simplement en erreur...
De telle sorte que pour utiliser ton proxy JSON, il devient obligatoire de déclarer un protocole formel...
Chomage en ce moment malheureusement, et pas vraiment de pistes sérieuses... Donc temps libre à foison (partagé entre voir grandir mon fils, veille techno et battlefield 3).
En même temps j'ai fait un test rapide uniquement avec les sources du projet GitHub que tu as donné.
En tout cas c'est fou ce que l'on peut faire avec le runtime ObjC.
C'est très dommage ça ! (pour rester poli)
Sinon, perso je n'utilise jamais de switch, un if le remplace la plupart du temps. J'ai tendance à penser que moins il y a de mots clé dans un language, mieux c'est. Mais l'expérimentation est toujours intéressante.
Il y a juste plus de fonctionnalité en ObjC c'est tout ^^
?
La quantité de mots clef du langage n'a d'impact que jusqu'à la compilation, ensuite on est en langage machine... C'est pas du Java hein :-)