Commentaires sur : Java c’est nul !

Par : Blaffard

Blaffard — Fri, 15 Oct 2010 08:52:26 +0000

Bonjour!
Je découvre en ce moment la programmation en Java.
Je n’en connait pas tout, je ne maîtrise pas les relations de polymorphise, covariance, surdéfinition, mais je crois que la solution est dans les classes génériques, permettant d’y traiter différent type d’objet et dans lesquels on y injecte pas des types primitifs (int, double) mais des object (Int, Double,..) pour lesquelles on pourra faire appelle aux methodes de la classe Objet.
Enfin, si j’ai bien compris …….

Par : Java Evangelist

Java Evangelist — Fri, 30 Apr 2010 10:44:46 +0000

Pierre Schambacher,

Java n’est pas nul, mais c’est toi qui es nul.

Par : Sébastien Mosser

Sébastien Mosser — Mon, 01 Mar 2010 09:21:51 +0000

en plus, j’ai répondu sans lire les autres commentaires (j’accumule …). Désolé du doublon .

Par : Sébastien Mosser

Sébastien Mosser — Mon, 01 Mar 2010 09:21:16 +0000

Ok, j’avais lu en diagonale ton post. Mais du coup, c’est pas « juste » parce que tu essaye d’avoir du polymorphisme sur tes paramètres?

La liaison dynamique en java se fait a la réception de message (=> quand ton instance de Main reçoit le message ‘trace’). Gait un google sur ‘late binding’, tu verras que c’est complètement normal …

Par : Pierre Schambacher

Pierre Schambacher — Mon, 01 Mar 2010 09:13:14 +0000

Mes collègues de boulot m’ont répondu pareil.
Je trouve ça un peu gênant car on aboutit à un résultat semblable qu’avec Java: un gros paquet de tests sur le type de l’objet. Cependant si j’avais à faire ça en Objectif C je passerais par une catégorie et contournerait ainsi le problème. Impossible de le faire en Java ^

Par : y!onel

y!onel — Mon, 01 Mar 2010 08:04:35 +0000

La nuit porte conseil : en fait en objectiveC c’est pas pareil : le choix d’une méthode ne se fait pas suivant les types. En gros déclarer des méthodes de même noms, mais avec des types différents en paramètre:
-(void) maMethode:(type1)var1
et
-(void) maMethode:(type2)var2

conduirait à une ambiguité, le compilo signalerait une erreur.
C’est pour ça qu’on souvent des noms de méthodes qui typent par leur nom :
-(void) maMethodeAvecType1:(type1)var1
et
-(void) maMethodeAvecType2:(type2)var2

Alors nul / pas nul ? je te laisse juge, au moins ça a le mérite d’être clair et d’éviter une potentielle incompréhention

Par : y!onel

y!onel — Sun, 28 Feb 2010 21:12:22 +0000

Je pense qu’en objectiveC c’est pareil Mais je ferai le test pour vérifier
OK, j’attends le prochain post sur la nullité de Java pour affuter de nouveaux contre-arguments ! :p

Par : Pierre Schambacher

Pierre Schambacher — Sun, 28 Feb 2010 21:07:10 +0000

Huhum … voilà qui explique tout.
Toutefois bien que le comportement est expliqué, il n’en reste pas moins peu pratique !! J’aimerais bien avoir le retour de programmeurs C++, C#, … sur un test comme ça voir si l’un d’entre eux se comporte comme je m’y attendais.
Puis-je compter sur toi pour tester l’Objectif C ?

PS: si Java c’est nul !! Mais j’ai assez grogné pour aujourd’hui, je ferais un autre billet pour me défouler une autre fois.

Par : y!onel

y!onel — Sun, 28 Feb 2010 20:45:15 +0000

Hum hum, d’abord, non ! java n’est pas nul
Pour m’être aussi mangé les dents là dessus, il ne faut pas confondre le polymorphisme, dynamique, qui s’applique aux objets sur lequels on appelle les méthodes, et le choix des méthodes en fonction des types de paramètres, qui est lui statique.
Le polymorphisme ne s’applique pas aux paramètres.
Je suis quasiment sûr que tu aurais le même problème en C++
Par contre si dans ton code, au lieu de main.trace(o) tu fais o.toString(), tu ferais appel réellement dans ce cas au polymorphisme, dynamique, qui trouverait la bonne méthode toString() en fonction du type de o , au runtime.

Par : Pierre Schambacher

Pierre Schambacher — Sun, 28 Feb 2010 18:48:43 +0000

Le problème est qu’en affichant « Object: java.lang.Integer » au lieu de « Integer » (notes l’absence de Object) je monte qu’il passe par la méthode trace(Object) et non pas par la méthode trace(Integer) ou trace(Float) qui est le comportement que j’attendais. J’ai ajouté le getClass().getName() pour éviter qu’on me dise qu’il s’agit « peut-être » d’un autre type que Integer ou Float.

Le fait est que la liaison est faite de façon statique, et non pas dynamique comme on nous le vend. Si c’était le cas il verrait à l’exécution que l’objet est un Integer, et appellerait la méthode avec la signature la plus proche du type voulu. J’ai découvert ce comportement avec un code très différent (impliquant des NSArray, NSMutableDictionnary et autres joyeusetés) mais le résultat est le même: si tu passes un Object en paramètre, il link l’appel à la méthode Object sans chercher à savoir si à l’exécution une autre méthode collerait mieux.