Reprise du message précédent :

bha je pense pas ... quand tu regardes bien, le nombre de méthode qui prend des tableaux en paramêtre est plutot limité ...

g du mal a comprendre leur exemple d'appel quand meme

ouais
c'est pour ce genre de cas où passer par des tableaux est une "bidouille" pour passer plusieurs paramêtres que c'est intéressant.

bha quoi ?
c'est quoi le soucis ?

 
ah nan c bon g rien dit

chi en fait :
 

 
question tres con : y faudra donc \ les { dans les strings pour pas que ca soit considere comme caractere special ?
 
{0,number,integer} : ca signifie quoi tout ca ?

chrisbk: la signature actuelle de cette methode est
String format, Object[] parameters
 
donc la premiere string (avec les {}) on s'en tape ça n'a rien à voir

 

 
 
je vais aller me noyer et je reviens

Quelqu'un sait comment on récupère ses arguments dans la méthode à nombre d'arguments variable ?
 
edit : je suis saisi d'un effroyable doute, ça serait pas tout connement implémenté avec les metadata dont on a pas la doc ?¿?

j'suis qu'un p'tit junior en java mais après avoir lu j'ai plutôt l'impression que ça va rendre le code illisible la plupart du temps... non ?

   
 
je vois pas en quoi le code serait moins lisible !  
 
Implémentation :
public Object newInstance (Object... args)
c'est pareil que  
public Object newInstance (Object[] args)
le corp de la méthode sera le même ! Donc à écrire ou à relire c'est pas plus difficile.
 
 
Utilisation:
constr.newInstance(new Object[] {"c'est", "portant" "simple"});
C'est pareil (en moins clair) que  
constr.newInstance("c'est", "portant" "simple" );
 
 
En quoi ca vous pose un problème ??? C'est juste une facilité d'écriture !
 
Evidement, il faudra éviter d'avoir une dizaine de méthodes du même nom avec certaines un arguments en varargs car là ca va être difficile de savoir laquelle est appelée (de toute façon, en cas de littige, le compilateur jettera).
Mais bon, ca c'est comme dans n'importe quoi : si on veut vraiment faire un code de merde, quelque soit le langage on y arrive toujours !

c'est moins clair à l'utilisation si la signature de la methode à d'autres arguments genre mamethode(String s, String... chaines)

et puis ça me fait pas peur pour ce qui est des classes de la jdk, mais plutot par rapport a ce que d'autres vont pouvoir ecrire comme cochoncetés avec ça

 
ben ça changera rien, un mauvais programmeur reste mauvais, c'est pas la fautes au specif  

nan, rien à voir avec les metadata.
 
Tu le récupères de la même façon que si c'était un tableau du type indiqué (j'ai pas vu d'exemple de code mais c'est ce que j'ai compris, et ca parait logique).
 
Les métadata sont assez flous pour moi aussi, mais en fait c'est un peu normal : c'est juste un concept. Il faut voir de quelle façon ca va être utilisé.
 
Je pense qu'il y aura un ensemble de metadata "standards".
ex : metadata 'overrides' pour les méthodes qui indique que la méthode surcharge une méthode de la class parente. Charge à l'IDE de vérifier cela.
 
Ensuite, j'imagine que chaque constructeur va rajouter sa couche de metadata (nottament dans les solutions J2EE). Là j'ai un peu peur que ca foute le bordel ... Ca risque de devenir une multitude de mini-langages propriétaire au sein du langage Java.
Mais bon, je pense que ches Sun ils ont pensé à ca avant moi et qu'il vont s'assurer et spécifier les choses pour que les dérives soient limitées au maximum !

   
en quoi c'est moins clair ? le 1er param c'est 's', les éventuels autres c'est 'chaines' ...

ben si les specs permettent des choses qui peuvent etre crades, un peu quand meme
au moins sans ça, un mauvais programmeur faisait du code plus ou moins lisible malgré tout (apres un "code layout" )

bha tu vois je pense pas ...  
De toute façon cette feture existe dans d'autres langage, et elle est très peu utilisée : quelques classes des librairies standards (ex : printf)

bon on va pas s'eterniser la dessus, on a un point de vue different, c tout
(ils t'ont drogué chez sun ou quoi? )
 
on verra ça une fois que ça sera dispo... je changerai pê d'avis.. ou bien toi

mais en quoi son code sera moins lisible avec ca    

euuuh... merde alors, ils devraient ptet mettre un GOTO dans java alors?

stooooooooooooop

bha nan ...  
y a certains trucs sur lesquels je suis sceptique (autoboxing, metadata, un peu les generics aussi), mais ce truc là je crois vraiment pas que ca peut poser des problèmes ...

bha nan. quand ca existe c'est bcp trop utilisé le goto.
 
Ce que je voulais dire c'est que même si t'as un mauvais developpeur, il va pas s'amuser à foutre ce machin là partout parec que dans la plupart du temps, ca n'a pas d'utilité.

j'ai écrit 2 fois "bha nan"

Surtout qu'en plus on écrit "ba nan" ou "bah nan"

Je lis qu'on peut annoter directement des méthodes, comme le nombre d'arguments variable n'est qu'un problème syntaxique (bon, un peu de type, mais ils avaient cas virer les types primitifs), ça me parraît tout-à-fait possible.

c'est pas qu'un problème syntaxique : le compilo doit faire le boulot en plus : c'est lié au code ! pas au metadata. Le compilo s'en cogne des metadata.
 
Les metadata sont destinés aux outils de dev, pas au compilateur lui même.
 
de toute façon, les slides que j'ai filé ils sont juste. c'est pas moi qui les ai fait. c'est sun

Le pb c'est que je les ai jamais vus, ils sont trop sombres.

Moi j'aurais préféré qu'ils étendent le langage pour simplifier la création d'un tableau, comme suit :
 
constr.newInstance({ "c'est", "portant", "simple" });
 
équivalant bien sûr à :
 
constr.newInstance(new Object[] { "c'est", "portant", "simple" });
 
 

ca ca marcherait quand tu veut des Object[]. Comment spécier le type du tableau ?

'tain, je connaissais même pas cette syntaxe, elle est cool, je faisait toujours une variable intermédiaire !

 
Justement, l'avantage d'une telle syntaxe, c'est que le compilateur, connaissant le type (à la compilation) de chacun des éléments du tableau, pourrait définir le tableau comme tableau de classe ancêtre la plus spécialisée de toutes les instances listées.
 
Par exemple, avec la nouvelle fonctionnalité d'autoboxing :

pourrait être équivalant à :

ha ben non !!! ca ca va pas du tout ! c'est beaucoup trop floux !
En plus on connait pas forcément le type de l'objet à la compilation donc c'est pas possible  
 

Ha, là je suis d'accord à 150% avec benou. 'faut rester un minimum strict bordel, sinon, on va où ?

bha ouais ... c'est pas du javascript quoi

penser ... désolé, c'est trop dur!