Discussion :

[infotunis]

A la suite de la forte demande de la surcharge d'opérateurs en java surtout dans le calcul numérique, Enfin le projet GPL (open source) de spécification et d'implémentation de la surcharge d'opérateurs sur javac : jo2 (java oveloading operator).
Vous pouvez télécharger le compilateur javac étendu et sa documentation pour pouvoir écrire le code :
Matrix A,B,C;
...
C=(A*3+B)*2;

Tout est sur le lien : http://sourceforge.net/projects/jo2

[CyberChouan]

Très bonne initiative... mais ce post aurait plus sa place dans un topic flaggué en entête du forum, du style "Quels Frameworks/librairies JAVA utilisez-vous?", un peu sur le même principe que "Avis sur les meilleurs programmes JAVA".

Avis aux modérateurs...

[®om]

Vu que sur le lien que tu donnes, il n'y a que le projet sourceforge, et non un site, pourrais-tu donner des exemples d'utilisation. Par exemple comment définir un nouvel opérateur sur une classe...

[infotunis]

Il y a une documentation qui comprend la spécification, la conception et un exemple complet d'utilisation (entre classes matrices).
Pouvez télécharger le projet juste en tapant la commande :
svn co https://jo2.svn.sourceforge.net/svnroot/jo2 jo2
Vous y trouverez une doc et le projet lui même qui n'est autre que javac étendu,
Pour tester le compilateur : placez vous dans le répertoire compiler (tout comme en javac) et vous trouverez un Readme "!!ReadMe EXTENDED" qui vous guidera pas à pas pour compiler le projet et obtenir le jar correspondant.

Remarque : Utilisation de svn
- sous windows : vous pouvez par exemple installer un plugin subversion pour eclipse
- sous linux vous pouvez utiliser soit eclipse ou installer subversion et executer la commande :
svn co https://jo2.svn.sourceforge.net/svnroot/jo2 jo2

pour plus de détails ou de question n'hésitez pas à me contacter ou rejoindre le forum de jo2 sur le site sourceforge.

[deltree]

Très bonne chose en tous cas, notamment pour les classes BigDecimal et BigInteger que j'ai pas mal utilisé.
Ce sera beaucoup plus lisible que les add(...).multiply().
Par contre, j'espère que ce sera bien intégré justement aux classes opérable avec des add etc. pour qu'on puisse s'en servir sur ces types, et qu'on puisse simplement affecter le "+" aux "add" et éventuellement utiliser les 2 syntaxes.

Pourtant je ne suis pas trop fan des dernières évolutions de syntaxes du Java 5, mais là ça semble logique.

[infotunis]

Ce concept marche pour les classes nouvellement définies ainsi que pour les classes prédéfinies par java :

Pour une classe nouvellement définit par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
public class Complex {
 
public Complex (int re,int im) { 
this.re=re;
this.im=im;
}
private Complex "+" (Complex C1, Complex C2) {
return new Complex(C1.re + C2.re , C1.im + C2.im);
}
 
private Complex "*" ( int i , Complex C1) {
return new Complex(C1.re * i , C1.im * i);
}
private Complex "--" (Complex C1) {
return new Complex(C1.re --, C1.im -- );
}
 
public static main () {
int coef=4;
Complex Z1, Z2, Z3;
Z1 = new Complex(3, 5);
Z2 = new Complex(6, 2);
Z3=Z1-- + (coef *Z2);
}
 
private int re;
private int im;
}

Pour une classe prédéfinie dans java telle que BigDecimal ou BigInteger ...:
On peut hériter de cette classe et ajouter la définition de surcharge d'opérateurs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class XBigDecimal extends BigDecimal {
// initialisations des constructeurs de XBigDecimal
// public XBigDecimal () {
// super();
//}
// ...
// puis on définit tous les opérateurs qu'on veut entre une classe XBigDecimal et n'importe quelle autre classe ou type primitif.
 
private XBigDecimal "+" (XBigDecimal B1,  XBigDecimal B2) {
B1.add(B2);
// ou n'importe quel code voulue à condition qu'il préserve le sens de +.
}
}

[sinok]

On va dire que pour les forks de java va falloir y réfléchir...

De même quel est votre plan vis à vis du suivi des devs sur le JDK car là c'est une version qu'on pourrait qualifier de bêta au max (pas de release, pas de site, obligé d'aller pomper le code sur SVN et de le compilar à la mano).

De même au niveau de la compatibilité du bytecode çà donne quoi, je suppose bien que ces redéfintiion d'opérateurs ne sont que du sucre syntaxique à l'image des generics introduits dans java 5 et qu'ils sont perdus au runtime...

Le sujet pour les programmes est destiné à des ... programmes et non des outils de dev, celui des API aux API stable et utilisable sans soucis par le membre du forums.
Donc pour l'instant je ne suis pas franchement d'intégrer un fork du JDK dans nos références pour le moment, et ce pas avant la release finale de java (aka openjdk) car on a le temps de voire venir. Le seul fork qui pourrait être envisageable serait IcedTea (et encore ce n'est pas réellement un fork: il remplacent les élements non libres du jdk 7 par les équivalents issus de classpath) car il vise le remplacement des plugs proprio de l'openjdk par du 100% open source, mais même sur ce plan là il sont en retard par rapport aux devs d'openJDK.

[Ricky81]

Très bonne initiative... mais ce post aurait plus sa place dans un topic flaggué en entête du forum, du style "Quels Frameworks/librairies JAVA utilisez-vous?", un peu sur le même principe que "Avis sur les meilleurs programmes JAVA".

Avis aux modérateurs...

Ca existe dans le forum APIs ou ce sujet a d'ailleurs davantage sa place.
cf. http://www.developpez.net/forums/showthread.php?t=24422

[CyberChouan]

Ca existe dans le forum APIs ou ce sujet a d'ailleurs davantage sa place.
cf. http://www.developpez.net/forums/showthread.php?t=24422

Bien vu... je n'avais pas pensé à aller regarder les sujet flaggués des sous-forums: mea culpa! Je le saurai pour la prochaine fois que le cas se présentera...

P.S. Du coup, peut-être pourrais-tu envisager de déplacer ce post là-bas (après accord de son auteur)

[Ricky81]

P.S. Du coup, peut-être pourrais-tu envisager de déplacer ce post là-bas (après accord de son auteur)

Ca touche quand même un sujet plus large, à savoir les forks. Donc pour l'instant il ne vaut mieux pas mélanger.
D'ici à ce qu'il y ait d'autres discussions de ce type sur des forks, on en fera sans doute un post-it dédié.

[bulbo]

Moi qui me felicitait que ca n'existait pas en java, ya fallu que quelqu'un le fasse

Bon pour le moment c'est juste du sucre syntaxique et je suppose que le + entre 2 objets ne redefinissant pas l'operator fera echouer la compil.

Mais serieusement c'est un cauchemard cette surcharge, la lecture du code en devient deux fois plus difficile, le + n'est pas trop le probleme mais quand le = est surcharge et qu'une affectation n'est plus qu'une affectation mais que d'autres choses sont faites en meme temps, la commence les problemes.

Lorsque Sun n'a pas mis la surcharge des operateurs ce n'etait pas un oubli ou qu'ils trouvaient ca trop dur a implementer, c'est plutot qu'ils ne voyaient vraiment pas ca comme quelque chose de souhaitable dans un langage et je les rejoins a 100% la dessus.

Aujourd'hui avec les IDE modernes un simple Ctrl-click sur un appel de methode et on peut consulter le code de la dite methode par contre qui pensera a faire un Ctrl-click (si c'est implemente un jour) sur un = ?

Si on ne peut plus faire confiance aux mots cles du langage et qu'il faut a chaque fois verifier qu'elle semantique a ete rajoute a une affectation, comment le developpeur a implementer une addition de deux clients par exemple .. on perd beaucoup de temps.
Le developpeur gagne 5s a ecrire + au lieu d'un nom de methode qui en dirait plus long, perd 2min a surcharger l'operateur et tout ceux qui devront relire du code utilisant ce truc perdront des plombes parce qu'un operator fera des choses en douces et qu'il est plus facile de rater un caractere +,-, = qu'une appel de methode.

Bulbo