Literal Syntax for NSArray, NSDictionary & NSNumber

muqaddar · mars 2012

Tiens, je viens de tomber sur ce post.

Sympa tout ça !

Donc pour un dico:

NSDictionary *tweet = {

@site: @CocoaCafé.fr,

@admin: @muqaddar,

@timestamp: 1331664532

};

Ceetix · mars 2012

Oui il me semble que ce sera dispo à la sortie de ML.

C'est pas sous NDA ?

zoc · mars 2012

Non, puisque c'est disponible dès maintenant dans le code source de LLVM, qui n'est pas sous NDA. Tu peux même t'amuser à compiler la dernière version de clang pour en profiter sur Lion...

muqaddar · mars 2012

'zoc' a écrit:

Non, puisque c'est disponible dès maintenant dans le code source de LLVM, qui n'est pas sous NDA. Tu peux même t'amuser à compiler la dernière version de clang pour en profiter sur Lion...

Tu passes ton temps à faire de la veille techno ma parole !

Ceetix · mars 2012

Et de la vieille techno vu que j'ai même pas bon.

En tout cas c'est super cool cette nouvelle notation !

System · mars 2012

'Ceetix' a écrit:

Et de la vieille techno vu que j'ai même pas bon.

En tout cas c'est super cool cette nouvelle notation !

Faudrait juste pas que ça devienne une habitude de vouloir tout simplifier non plus.

Mala · mars 2012

Pour une fois qu'un langage est "humainement" pas trop incompréhensible, on le rend plus obscure. Je suis le seul à trouver ça dommage ce genre de nouvelle syntaxe?

Mala · mars 2012

'muqaddar' a écrit:

Tu passes ton temps à faire de la veille techno ma parole !

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='::)' />

Apple committed a new patch to the llvm project adding support for new Objective-C literal syntax for NSArray, NSDictionary and NSNumber. These have previously been documented in the Mountain Lion Xcode release notes but that was still under NDA. Now that these features have been committed to llvm I guess we're allowed to speak about it.

...and since LLVM isn't under NDA like most of the "developer preview" stuff, this means we can all finally discuss this stuff on our blogs!

System · mars 2012

'Mala' a écrit:

Pour une fois qu'un langage est "humainement" pas trop incompréhensible, on le rend plus obscure. Je suis le seul à trouver ça dommage ce genre de nouvelle syntaxe?

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)

Draken · mars 2012

Très bon exemple :

NSArray *doctors = @[@&quot;Matt Smith&quot;, @&quot;David Tennant&quot;, @&quot;Tom Baker&quot;];

Draken · mars 2012

Oo.. le copier-coller est devenu bègue, ou quoi ?

AliGator · mars 2012

Moi je viens de découvrir un projet très intéressant qui permet en manipulant proprement le Runtime ObjC, d'écrire ce genre de trucs :

[[monObjet switch]<br />
  case:obj1 :^{<br />
	NSLog(@&quot;monObjet est égal à  obj1&quot;);<br />
  }<br />
  case:obj2 :^{<br />
	NSLog(@&quot;monObjet est égal à  obj2&quot;);<br />
  }<br />
  // ...<br />
  default:^{<br />
	NSLog(@&quot;Je ne sais pas à  quoi monObjet est égal&quot;);<br />
  }];

Et je trouve ça sympa, ça permet de faire des switch/case mais avec des objets plutôt que se limiter à pouvoir les faire avec des int

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 :

NSString* enStr = @&quot;Hello&quot;;<br />
<br />
[[enStr switch]<br />
  case:@&quot;Hello&quot; :^{<br />
	NSLog(@&quot;Bonjour&quot;);<br />
  }<br />
  case:@&quot;Bye&quot; :^{<br />
	NSLog(@&quot;Au revoir&quot;);<br />
  }<br />
  case:@&quot;How are you?&quot; :^{<br />
	NSLog(@&quot;Comment allez-vous ?&quot;);<br />
  }<br />
  default: ^{<br />
	NSLog(@&quot;Je ne comprend pas %@.&quot;, enStr);<br />
  }];

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 ?

System · mars 2012

Tu entends quoi par manipuler proprement le runtime ObjC? Il y a quelque chose à faire pour que les switch sur objets soient valables? Parce qu'effectivement je trouve ça très intéressant !

yoann · mars 2012

'ldesroziers' a écrit:

Tu entends quoi par manipuler proprement le runtime ObjC? Il y a quelque chose à faire pour que les switch sur objets soient valables? Parce qu'effectivement je trouve ça très intéressant !

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.

devulder · mars 2012

'AliGator' a écrit:
Moi je viens de découvrir un projet très intéressant qui permet en manipulant proprement le Runtime ObjC, d'écrire ce genre de trucs :
[[monObjet switch] 
 case:obj1 :^{ 
	NSLog(@&quot;monObjet est égal à  obj1&quot;); 
 } 
 case:obj2 :^{ 
	NSLog(@&quot;monObjet est égal à  obj2&quot;); 
 } 
 // ... 
 default:^{ 
	NSLog(@&quot;Je ne sais pas à  quoi monObjet est égal&quot;); 
 }];
Et je trouve ça sympa, ça permet de faire des switch/case mais avec des objets plutôt que se limiter à pouvoir les faire avec des int

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 :
NSString* enStr = @&quot;Hello&quot;; 
 
[[enStr switch] 
 case:@&quot;Hello&quot; :^{ 
	NSLog(@&quot;Bonjour&quot;); 
 } 
 case:@&quot;Bye&quot; :^{ 
	NSLog(@&quot;Au revoir&quot;); 
 } 
 case:@&quot;How are you?&quot; :^{ 
	NSLog(@&quot;Comment allez-vous ?&quot;); 
 } 
 default: ^{ 
	NSLog(@&quot;Je ne comprend pas %@.&quot;, enStr); 
 }];
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 ?

Ce qui serait bien c'est les choix multiples du genre:

case 1,2,3:

case 1 to 10:

System · mars 2012

C'est propre ça ? ^^ Ou plutôt, non risqué?

JegnuX · mars 2012

'AliGator' a écrit:

Moi je viens de découvrir un projet très intéressant qui permet en manipulant proprement le Runtime ObjC, d'écrire ce genre de trucs [...]

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é !

Et ce projet est open-source ? Un lien github à donner peut etre ?

/smile.png' class='bbc_emoticon' alt=':)' />

AliGator · mars 2012

Ah oui pardon je n'ai pas donné le lien : https://github.com/n-b/objcswitch

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é

#pragma clang diagnostic ignored &quot;-Wincomplete-implementation&quot;

mais ça n'a pas l'air de suffire.

System · mars 2012

Intéressant, merci !

Mala · mars 2012

Le switch/case ça j'aime mieux déjà !

/thumbsup.gif' class='bbc_emoticon' alt='' />

Cela a une réelle utilité au moins.

yoann · mars 2012

'AliGator' a écrit:
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é
#pragma clang diagnostic ignored &quot;-Wincomplete-implementation&quot;
mais ça n'a pas l'air de suffire.

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".

AliGator · mars 2012

C'est très dommage car je m'étais déjà posé la question pour développer une classe proxy (à la NSProxy), ou genre pour implémenter un objet qui sert de proxy à un WebService (en gros, j'avais déjà fait un objet JSONRPCServiceProxy qui traduit au runtime les appels de méthodes qu'on lui envoie en appels au WebService, [aJSONRPCServiceProxy getInfoForPersonId:1234] étant converti en appel à la méthode "getInfoForPersonId" du WebService via une NSURLConnection, avec comme paramètre 1234, retournant la réponse en asynchrone une fois que le WS a répondu)

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((...)) ?

Lexxis · mars 2012

'AliGator' a écrit:
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é
#pragma clang diagnostic ignored &quot;-Wincomplete-implementation&quot;
mais ça n'a pas l'air de suffire.

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.

AliGator · mars 2012

Ah ben j'ai dû m'emmêler les pinceaux alors parce que j'avais justement testé avec LLVM (du moins il me semblait) ayant bien conscience qu'il fallait que je fasse gaffe à utiliser LLVM et pas GCC, et j'avais toujours le warning... mais en même temps il était tard donc je me suis peut-être fourvoyé. Faudra que je reteste alors.

zoc · mars 2012

'AliGator' a écrit:

C'est très dommage car je m'étais déjà posé la question pour développer une classe proxy (à la NSProxy), ou genre pour implémenter un objet qui sert de proxy à un WebService

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...

zoc · mars 2012

'muqaddar' a écrit:

Tu passes ton temps à faire de la veille techno ma parole !

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).

Lexxis · mars 2012

Pour GCC j'ai dû faire quelque modifications pour que la compilation s'effectue sans erreur. Peut-être que cela dépend simplement de la version de LLVM (j'utilise la dernière version de Xcode - 4.3.1) ou de l'emplacement de l'utilisation du pragma.

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.

AliGator · mars 2012

En même temps si comme le dit zoc avec ARC ça se transforme en erreur, ça veut dire qu'on ne peux plus du tout utiliser les possibilités de résolution dynamique de méthode avec ARC, puisqu'il y a erreur à la compilation même si ça sera résolu au Runtime ?!

C'est très dommage ça ! (pour rester poli)

groumpf · mars 2012

Tout cela ressemble fortement à Groovy (les init statiques + interception des méthodes à l'exécution) sauf que c'est plus simple en Groovy

/rolleyes.gif' class='bbc_emoticon' alt='::)' /> Il n'y pas de @ ni ^ ... C'est quand même un peu batard l'Objective-C, bon je me tais sinon je vais me faire tuer ...

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.

yoann · mars 2012

'groumpf' a écrit:

Tout cela ressemble fortement à Groovy (les init statiques + interception des méthodes à l'exécution) sauf que c'est plus simple en Groovy /rolleyes.gif' class='bbc_emoticon' alt='::)' /> Il n'y pas de @ ni ^ ... C'est quand même un peu batard l'Objective-C, bon je me tais sinon je vais me faire tuer ...

Il y a juste plus de fonctionnalité en ObjC c'est tout ^^

'groumpf' a écrit:

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.

?

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 :-)

System · mars 2012

Joli troll

Literal Syntax for NSArray, NSDictionary & NSNumber

Réponses