classe "récursive" et héritage - Page 2

GoldenCrystal (./30) :
En général c'est une bonne idée, mais pas en java. A ce que j'ai compris quand on me l'avait expliqué les generics de Java ont plutôt tendance à rajouter des casts (implicitement) qu'a en retirer comme c'est le cas en C++ ou C#.

En effet en Java les generic sont juste un système de sucre syntaxique qui masque des casts.
Dans un cas comme les conteneur, c'est un réel gain en lisibilité.
Pour moi un ClasseHeritee extends ClasseDeBase<ClasseHeritee> est quelquechose de moche, pas vraiment évident a comprendre et inutilement complexe a déclarer.

ah carrément, c'est juste des casts? y'a un support de la VM quand même, non?

squalyl (./32) :
y'a un support de la VM quand même, non?

Non, le but c'était justement de ne pas avoir à modifier la vm. Du coup tu peux utiliser des classes avec "generics" dans du Java 1.4.

Absolument rien n'est fait au niveau de la VM.

List<Truc> list = new List<Truc>();
Truc monTruc = list.get(0);

génere le même bytecode que:

List list = new List();
Truc monTruc = (Truc)list.get(0);

C'est juste du sucre syntaxique géré par le compilateur pour rendre le code plus lisible(si bien utilisé) et empecher d'utilser une classe non cohérente (comme mettre un String dans un List<Truc>)

oué c'est quand même un gain important que ça teste en compile time

ok. ils ont confiné ça au niveau de la sémantique, donc t'as des jolis vérifications de type en plus au niveau du compilo mais aucun overhead.

c'est sympathique

Uther (./34) :
Absolument rien n'est fait au niveau de la VM.

List<Truc> list = new List<Truc>();
Truc monTruc = list.get(0);

génere le même bytecode que:

List list = new List();
Truc monTruc = (Truc)list.get(0);

C'est juste du sucre syntaxique géré par le compilateur pour rendre le code plus lisible(si bien utilisé) et empecher d'utilser une classe non cohérente (comme mettre un String dans un List<Truc>)

Ca génère le même bytecode ? C'est dommage, le cast vers Truc est censé être sûr dans le premier cas donc on pourrait éviter la vérification de type à chaque cast

le cast génère un bytecode? je sais pas, malgré l'existence d'un opcode "checkcast"

http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc2.html#checkcast

Pourtant le compilateur ET le vérifieur pourraient être sûrs du cast.

Donc j'ai pas testé une décompilation mais il génère pas forcément d'opcode checkcast là.

Bon voilà, j'ai terminé mon projet. Merci à vous, même si par manque de temps je n'aurais pas pu prendre en compte vos explications et aurait du me tourner vers d'autres solutions.

Si certains sont curieux, il est ici : Fichier joint : Projet Java 2008.zip

C'est un programme qui affiche tous les chemins possibles entre deux villes.

Thibaut (./28) :
Merci "instanceof" ça correspond à "is" en C++ (à moins que ce soit en Pascal Objet) ?

C'est un is effectivement, mais is n'est pas du C++, c'est du VB ou du Delphi.

En C++ avec QObject, c'est obj->inherits("MyClass").

Avec le RTTI C++, il me semble qu'il faut mettre if (dynamic_cast<Class *>(obj)) pour tester ça.

"if (myObject is ClassA)" ou "myInstance = myObject as ClassA;" c'est quand même carrément plus classe que ces syntaxes ignobles

Donc is existe en C++ ?

Non, c'est du C# ça.

yep, ou moyennant un ":=" à la place du "=" ça pourrait être du Delphi aussi; je trouve que leurs syntaxes de cast (même si ça n'est pas quelque chose qu'on est supposé utiliser souvent) sont bien plus pratiques que "dynamic_cast<Class *>" (très lourd) ou "obj->inherits("MyClass")" (encore pire : on utilise une chaine de caractère pour la comparaison ; même si ça reflète le mécanisme interne, sémantiquement je trouve ça ignoble)

je préfère le lolcode:

<variable> IS NOW A <type>         BTW equivalent to
<variable> R MAEK <variable> [A] <type>

#define is(t) ->inherits(#t)
if (obj is(MyClass))

T'es pas rigoureux. Il vaut mieux mettre la définition entre parenthèses.

Kevin Kofler (./46) :

#define is(t) ->inherits(#t)
if (obj is(MyClass))

Certes mais c'est limité au QObject et oblige donc je pense a passer par le système QT du moc.

Thibaut (./47) :
T'es pas rigoureux. Il vaut mieux mettre la définition entre parenthèses.

Dans ce cas la je pense que ca serait plutôt problématique.

s/problématique/impossible/
Ça donnerait obj(->inherits("MyClass")), un erreur de syntaxe.

Bref ton define est à proscrire

Thibaut (./47) :
T'es pas rigoureux. Il vaut mieux mettre la définition entre parenthèses.

Non ça pose pas de problème, parce qu'il n'y a rien qui aurait une priorité plus élévée que ->methode() ^^ (enfin ça reste moche )

Zephyr (./41) :
"if (myObject is ClassA)" ou "myInstance = myObject as ClassA;" c'est quand même carrément plus classe que ces syntaxes ignobles

Je pensais que t'allais dire ActionScript 3.0, vu que ces deux expressions sont valables et il me semble que t'aimais bien l'AS.

Je connais pas trop l'AS 3.0, ça fait longtemps que je n'y ai pas touché, mais de mémoire les versions précédentes étaient plutôt pas mal oui ^^ (ceci dit je trouve aussi le JavaScript, à quelques exceptions près, très bien fichu)

oué, le js c'est bien mais si il était un peu plus férocement typé on éviterait certains bugs chiants

c'est surtout qu'il fonctionne en duck-typing (les notions de "fortement typé" ou "faiblement typé" me semblent toujours aussi vagues), mais bon c'est un peu le concept du langage en même temps.

fortement pour moi c'est "explicite" comme C ou java

OK c est explicite mais faiblement typé.

Bon, OK, j'aime pas JS car il n'est pas explicitement typé et ça mène a pas mal de confusions.

En fait, les termes corrects sont plutôt typage statique et typage dynamique. Et justement dans AS 3.0 (en fait ECMAScript-262 4è édition encore en développement mais apparemment suffisamment stable pour que Macromedia base Flex dessus), il y a un support de la POO par classe en plus de la POO par prototype.
J'imagine, mais j'ai jamais lu clairement, que dans quelques temps, cette version du langage devrait aussi être adoptée par JS dans les navigateurs, et c'est pas pour me rassurer.

Pour troller, je dirais que c'est vraiment pour plaire aux noobs qui connaissent que le Java, alors que ces derniers devrait s'ouvrir un peu à d'autres concepts mais bon...
Sans troller, c'est sympa d'avoir un langage qui permet d'être totalement dynamique, et lorsque c'est vraiment nécessaire (ou pour la librairie standard après tout, tant qu'ils utilisent pas final ce qui empêche de rajouter des trucs persos à la classe String par exemple... #expérience#), pour des raisons de performance ou de complexités trop importante, de passer à du statique certains endroits précis.
En gros, quand t'es tout en statique, tu passes ton temps à coder du code qui sert à rien, qui est là juste pour faire plaisir au compilo, à la Java quoi...

C++ avec MFC: if( obj->IsKindOf(RUNTIME_CLASS(MyClass))

Le as de C# correspond à dynamic_cast<> en C++ et n'a pas d'équivelent direct en java.
Le cast de Java correspond à celui du C#, ou au safe_cast<> du C++/CLI.
Le instanceof de java correspond au is du C# et n'a pas d'équivalent direct en C++, mais il ne faut pas oublier que obj is MyClass est équivalent à (obj as MyClass)!=null, d'ou l'emploi du dynamic_cast<> comme l'a montré Kevin.