Reprise du message précédent :

Ah bon ? Tu m'apprends un truc, là... Et comment y fait, le compilo, s'il connait pas le type de l'objet ?
 
...
 
Je vais t'aider un peu : quand il ne connait pas le type d'un objet, le compilo, il fait pas, tout simplement.
Tout objet est au moins une instance d'Object (on élimine évidemment le problème des atomiques ici), donc on connait son type. Au moins par défaut. Et tous les littéraux ont également un type (exemple "toto" a pour type java.lang.String).

 
 
merci de me prendre pour un neuneu ...
 
je trouve que ton truc est une mauvaise idée.  
 
et dans ton exemple, tu ne donne pas la déclaration de array. C'est un peu facile...
 
Et si c'est pour se rerouver avec des tableaux d'Object partout, je vois pas l'intérêt. Je préfere de beaucoup donner le type !

et en plus, dans ton exemple, je ne vois vraiment pas pkoi il irait sucer de son pouce que ce que tu veux c'est un tableau de Number ...

Je recentre le débat. Le point de départ, c'était "Object... args" versus "Object[] args", sachant qu'à mon sens, la première syntaxe impose de modifier la définition du langage, et pas la 2ème.
 
Tout ce que je dis, c'est que la première syntaxe n'apporte rien d'autre qu'une simplification d'écriture (on n'a pas à écrire "new Object[] " lors de l'appel de la fonction), et que cette simplification d'écriture aurait pu être atteinte en permettant d'écrire "{"toto", "titi"}" en lieu et place de "new Object[] {"toto", "titi"}".
C'est tout.

Ils feraient mieux de nous mettre la possibilité des appels par continuation dans la VM et de simplifier la syntaxe des classes internes anonymes que de nous mettre des fonctions à nombre d'arguments variable (surtout que le plus souvent ça se traduit par des parsers à l'exécution ce genre de trucs).

Ok, c'est pas comme ca que je l'avais compris.
 
Mais mon argument du typage reste valide ... Par exemple, la syntaxe varargs permet de préciser que tu veux une suite de paramêtre d'un certain type. ex:

 
la syntaxe que tu proposais ne permet pas au compilo de savoir de quel type doit être le tableau à créer en regardant uniquement le bout de code. Il faudrait qu'il cherche dans les signature de methode porui savoir quel type de tableau utiliser. Et ca il ne le fait pas.
 
Et puis, je trouve plus sympade ne pas avoir à mettre les accolades.
 
Et puis je ne vois pas bien en quoi ca "impose de modifier la définition du langage"   . C'est une évolution, quoi ...

  cékoidon ?

les varargs, c de la blague, de la poudre aux yeux, c'est utilisé une fois tous les 80 ans, pas la peine de crier au génie ou meme de s'etriper dessus, l'utilisation est des plus restreinte

c'est un peu ce que j'ai dit y a quelques posts ...

surement alors je vois pas pkoi on se chauffe la dessus

c'est prévu pr kan ?

fin d'année

Remplacer un appel de fonction par un jump simple avec arguments, en gros.
L'un des trucs les plus utilisé de cette technique est de faire des appels récursifs terminaux qui ne font pas grossir la pile proportionellement aux nombre d'appels.
Mais il y a d'autres trucs rigolots à faire aussi avec.
 
mots pour google : continuation passing style
 
Si t'as du temps, apprends la technique, elle vaut le coup.

c'est un goto avec paramêtres quoi ...

Sémantiquement oui, mais on s'en fout, c'est un bytecode en plus à mettre dans la VM et des compilos à adapter, de dehors ça se voit pas, sauf en complexité.

 
fichtre ca a l'air interessant, ca, thks

c'est quoi exactement l'intérêt ?
supprimer la pile d'appel ?
 

Quand ils ont inventé ça c'était un joujou de labo mais aujourd'hui c'est super-utilisé en optimisation. Tu ne fait pas grossir la pile d'appel si c'est pas nécessaire. C'est aussi utilisé pour d'autres analyses mais pas pour des langages à évaluation "avide" comme java et ses potes.

les modifs de la JDK 1.5 ne changent pas la JVM, c'est uniquement des modifs du compilo

On commence à le savoir !

ben on dirait pas puisque tu voulais qu'ils modifient le bytecode machin ...

 
ben quoi ?
on a pas le droit de toucher au bytecodemachin ?

nan c'est interdit

question ridicule sur le java qui n'a pas sa place ici :
pourquoi ils n'ont jamais implanté en java des enums a la C ?
J'avouerais que je trouve ca + pratique que ces foutus varargs
fin de la question ridicule tagada pouet pouet

J'ai même pas le droit de penser qu'ils auraient mieux fait de la modifier que d'implémenter à l'arrache les templates et d'introduire des conneries de var_arg ? Sachant que ça reste compatible avec les programmes produits par les vieux compilos.

Hum, ils y sont dans la 1.5 ...

nan, je dis pas que c'est pas intéressant, je disais juste que c'était un choix qu'ils avaient fait ...
Ce que tu proposes c'est juste une augmentation de perfs comme la JVM en a déjà connu des dizaines.
Je dis pas que c'est pas intéressant, mais c'est juste pas dans le même registre puisque ca ne touche pas au programmeur (le code) ...

tiens, oui, http://jcp.org/aboutJava/community [...] /enum.html
 
j'aime bien leur iterateur, y'aura ca en C++ ca m'aurait evité de tps a autre des manoeuvre chelou a tendance degueu...

Non, c'est ouvrir la JVM à des styles plus larges, à des programmes plus expressifs, ça va pas changer énormément les perfs sur des programmes déjà écrits.

oyé oyé
 
tous les PDF des sessions javaone sont accessibles gratuitements contre une inscription sur le site.
 
http://servlet.java.sun.com/javaon [...] dex.en.jsp
 
 
y a notament une sur les évolutions du jdk 1.5 à laquelle j'ai assisté ...

 
 
...Une inscription à 99?. Quand même !  

Cote cour :
 
Autoboxing : pas trop tot...
 
Static imports : enfin !
 
Generics : question performances j'attends de voir (j'utilise mes propres STD qu'on a tunees pour nos besoins et que l'on genere automatiquement) sinon l'interet est bien la.
 
Typesafe enums : pourquoi pas
 
Metadata : c'est le debut de l'ere code java bordelique et impossible a relire, je le sens.
 
Cote coeur
 
Mais avant tout, pour en avoir parle avec Doug Lea et Greg Czajkowski l'ete dernier a ECOOP, ce que j'attends impatiemment depuis le temps ce sont les Isolates (JSR 121). Deja presents dans la ME, ca fait un moment qu'on les attends dans la JDK.
 
Pour rappel, les isolates permettent de separer plusieurs applications les unes des autres au sein de la meme VM, de les isoler (heap, variables statiques mutable). C'est un moyen de gerer plusieures applications de maniere efficiente, securisee et evolutive.
 
Finalement seront presents dans Tiger (J2SE 1.5)sous forme d'API. Enfin bon ca ca va etre reellement utile et nouveau (fruit d'une veritable recherche).

nan, c'est gratuit. L'inscription à 99$ c'est pour avoir les vidéos des sessions avec la retranscription du spitch.
Les pdfs seuls sont gratuits.

Intéressant...  

je suis le seul ici a developper encore avec le jdk 1.3    
 
jme dit que les 3/4 des gens disposent seulement de celui ci et nous voila deja au 1.5  

Ici c'est 1.1.8 Mais on passe doucement au 1.3.0 (nonon, pas le 1.3.1) d'ici septembre

euh pq 1.3.0 ?
expres pour avoir les bugs en rab?

Tu connais AIX ? Bon ba apparemment, sur cet OS, passer à la 1.3.1 demande un bon milliard de patches à appliquer. Et ici ils ont jugé trop important ce "mass-patching" pour que ça soit un préreq chez le client. Stout.

z'ont qu'a changer d'os

 
voila qui me rassure