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

[infotunis]

A Bulbo et à tout intérressé par "pourquoi est ce projet?.."



Je débute par un peux d'historique: on sait tous que java s'est inspiré des du langage c++ auquel on a enlevé les concepts succeptibles de générer des erreurs de programmation comme : les pointeurs, l'héritage multiple, la surcharge d'opérateurs...
Au cours de ces années, la nécéssité de la surcharge d'opérateurs s'est fait sentir surtout chez la communauté java utilisant le calcul numérique (Mathématiciens, éléctroniciens...). Et celà pour des raisons surtout de simplicité de lecture et d'écriture de code.
Et le débat sur l'intégration ou non de la surcharge d'opérateurs s'intensifia:



Sun MicroSystems :
«Java omet beaucoup de caractéristiques de C++ qui sont rarement utilisés, mal compris,
confondant, qui dans notre expérience apportent plus de peine que l'avantage. Ces caractéristiques
omises se composent principalement de la surcharge d'opérateurs (également le langage Java
comporte la surcharge de méthodes), de l'héritage multiple, et des conversions automatiques
étendus.»
Il y a un autre souci c'est qu'un programmeur peut définir des opérateurs avec une sémantique
bizarre, non intuitive. Auquel a répondu Conrad Weisert :
«N'importe quel programmeur si indisciplinés quand en définissant + pour faire la soustraction est
susceptible également de définir additionner de la même manière fallacieuse ou de commettre
toutes les sortes d'autres péchés de programmation. Les professionnels compétents sont peu
susceptibles de faire l'un ou l'autre.»
Guy Steele apporte sa solution : l'évolutivité d'un langage, et qualifie Java de langage évolutif.
Et si cette évolutivité permettrait d'apporter a Java la surcharge d'opérateurs, pourquoi ne pas le
faire? Même James Gosling, l'un des créateurs de Java, pourtant au début opposé à la surcharge
d'opérateurs, avoue :
«Et si vous regardez les personnes qui font de l'arithmétique complexe dans Java en ce moment,
c'est vraiment laid. Je veux dire, il est incroyablement laid.»




Imaginez qu'à chaque fois qu'on veut implémenter un instruction du type:

(a+b+c)*(d+e*f/j)
on la code :
((a.add(b)).add(c)).mult(d.add(e.mult(f.div(j))))


Imaginer dans un programme mathématique ou d'éléctronique (filtres numériques par exemple)...Une centaine de lignes ou plus écrites sous cette dernière forme quel lisibilité peut on attribuer à ce code et quelle maintenabilité peut on y exercer.


Mais je suis d'accord avec vous sur le point que lasurcharge d'opérateurs peut générer des comportements imprévisibles avec certains opérateurs comme le =, == ...
C'est pourquoi le projet à débuter par une spécification qui tend à limiter l'utilisation des opérateurs qui peuvent générer des comportements imprévisibles...Et je pense que j'ai fais les choix qu'il faut pour enfin surcharger les opérateurs :

** unaires : +, -, ++, --
** binaires : +, -, *, /, %, <, >, <=, >=
** d'affectation composée +=,-=, *=, /=, %= ( Rq: += est définit automatiquement suite à la définition de + ).

[bobuse]

En fait, pour que ça reste lisible et qu'on évite les pbs évoqués par Bulbo, il faudrait limiter cette surcharge à un simple mapping sur une fonction de l'objet.
Ainsi on y gagnerai en lisibité dans les cas de calcul notamment, et on ne prend pas le risque d'avoir un code compliqué caché derrière un simple opérateur.

Une solution pourrait aussi de redéfinir plutôt de nouveaux opérateurs pour ne pas confondre les opérateurs standards et les nouveaux. Du genre les faire précéder d'un point, ça donnerait un truc du genre :

Code :

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

A .= B .* C

[bulbo]

Reste que c'est un fork, qu'il a en l'espece peut de chance d'etre jamais integre par Sun et donc va demander
- soit a son auteur un travail constant pour se maintenir a jour avec les evolutions de Sun (ca durera ce que ca durera)
- soit aux gens utilisant le fork d'accepter de rester bloquer sur les versions de ce fork qui seront disponible.

Je suis d'avis que si Java est un tel cauchemard pour le calcul scientifique, pourquoi ne pas rester avec le C++ dans ce cas ?

Personnellement dans mon projet actuel nous avons une solution pour nos calculs scientifiques tout a fait satisfaisante et facilement maintenable et sans surcharge.

Ce que j'aime c'est l'argument "les bons programmeurs ils feront pas", c'est le genre d'arguments qui fait qu'aujourd'hui C++ est le pauvre langage qu'il est dont les qualites s'effacent tres vite derriere ses gros defauts (dont la surcharge fait parti).
Surtout que l'argument pour l'introduction de la surcharge est de faciliter la vie des Mathematiciens et electroniciens, dont coder n'est pas le metier donc pour 95% des cas ne font pas partie de la communaute des "bons programmeurs".

Pourquoi ne pas avoir choisi une approche scriptee ? Genre un langage de script mathematique avec interpreteur en Java ? Il y a deja Beanshell, Groovy et j'en passe, leur integration au langage ne provoque aucun fork et ils peuvent tranquillement beneficier des evolutions de la VM.

Bref je suis d'accord pour ne pas etre d'accord avec tout ce que Sun a virer du C++, d'ailleurs ils ont fait marche arriere avec l'auto-boxing sur les types primaires.
Mais si java est aussi populaire aujourd'hui c'est aussi parce que de par sa structure assez stricte et du fait qu'il est completement objet, il a force le developpeur java a adopter certaines regles de programmation et de bonne conduite.

Il y a toujours possibilite de faire n'importe quoi mais ce n'est pas la voie la plus frequemment choisie, j'en veux pour preuve les nombreuses questions sur le design et les designs patterns que nous avons sur nos forums java.

La nature (humaine aussi) fait que le chemin choisi est souvent celui offrant le moins de resistance. C'est pour ca qu'en C++ si un developpeur a le choix entre revoir son design objet pour avoir un truc propre ou juste caster comme une brute a la fin on sait quel chemin il choisira 90% des fois.

Un des autres inconvenients du C++ a ete son manque de specs (et d'API) officielles; manques que n'avait pas java et aujourd'hui on l'on voit le C++ se standardiser, on voit aussi java se de-standardifier a travers des forks de toutes sortes je ne suis pas sur que la communaute ai quoi que ce soit a y gagner.

Bulbo

[deltree]

D'accord avec toi bulbo, mais je voudrais repréciser mon exemple: c'est celui du monde Banquaire.

On doit manipuler des types monétaires qui ne doivent absolument pas être arrondi par calcul, comme c'est le cas avec des "double". Le type le plus adapté das ce cas est le "BigDecimal", or là où pour faire la même chose, même des Coboliste peuvent utiliser des expressions, en Java on se limite aux syntaxes add.multiply etc.

Les calculs financiers gagneraient à être écrits sous forme d'expression, quitte effectivement, à passer par un interpréteur qui mappe les + en add etc, et ne pas remettre en cause la syntaxe java actuelle.

Cependant sur ce point, si je ne suis pas pour intégrer toutes les facilités du C++, les opérateurs sont un des points que je regrette le + du C++, et celui que je regrette le moins sont les syntaxes archaiques de type :: *(var)-> et < > intégrée en partie aux templates, pardon les generics.