Surcharge d`opérateurs en Java

Surcharge d’op´ erateurs en Java
Philippe Baqu´e Charles-F´elix Chabert Christian Delb´e
Yannis Juan
Encadr´e par Thomas Graf
8 avril 2002
R´ esum´ e
Lanc´e en 1995 par Sun Microsystems, le langage Java ne cesse de
s’imposer au grand public, et s´eduit de plus en plus d’utilisateurs. Ce
succ´es est sans pr´ec´edent, puisque jamais dans l’histoire de l’informa-
tique, un langage de programmation n’a ´et´e aussi rapidement diffus´e et
adopt´e.
Cette popularit´e ascendante est motiv´ee par les nombreuses sp´ecificit´es
int´eressantes du langage (qui a aussi b´en´efici´e d’une tr´es large m´ediatisation).
Parmis ces caract´eristiques, les plus pertinentes nous semblent-ˆetre d’une
part la capacit´e de Java `a ˆetre facilement diffus´e sur le r´eseau grˆace `a
un interfacage tr´es simple avec celui-ci, d’autre part une interface de
programmation tr`es compl´ete et efficace, et enfin la fameuse portabilit´e
de Java : “Write once, run everywhere”.
Malgr´e cela, Java poss´ede quelques d´efauts inh´erents `a sa conception,
`a savoir une certaine lourdeur dans son interpr´etation. De mˆeme, il
n’existe pas d’interm´ediaireentre les types primitifs et les objets r´ef´erenc´es,
ce qui le condamne `a ˆetre peu efficace en ce qui concerne le calcul
num´erique.
Permettre aux utilisateurs de surcharger les op´erateurs num´eriques nous
semble ˆetre une bonne approche pour d´efinir les bases de ce qui pourrait-
ˆetre une impl´ementation plus efficace et plus commode pour le calcul
num´erique en Java.
Nous allons `a travers ce rapport introductif voir les diff´erentes approches
que nous privil´egions, celles que nous ´ecartons, et enfin nos motiva-
tions.
1

1 Pr´ esentation du sujet
Le sujet de ce projet est de proposer la sp´ecification d’un mod`ele de sur-
charge d’op´erateurs en Java, ainsi qu’une impl´ementation de r´ef´erence. Cette
impl´ementation sera int´egr´ee au compilateur KJC [1]. Ce sujet, et la fac¸on
dont il a ´et´e pos´e, nous laissent `a priori une grande libert´e dans les choix de
conception (approche par compilateur ou par pr´eprocesseur, ...) et dans l’im-
pact sur le langage Java (avec ou sans nouveau mot cl´e, modification de la
grammaire, ...).
Cette fonctionnalit´e est tr`es peu pr´esente sur le “march´e” des compilateurs
(ou pr´eprocesseurs) Java ´etendu, peut-ˆetre parce que c’est un sujet tr`es contro-
vers´e : l’utilit´e et les effets n´efastes de la surcharge d’op´erateurs (on traitera
de cette controverse dans la section 2). De plus, les quelques impl´ementations
existantes sont assez pauvrement document´ees, et pas toujours clairement
sp´ecifi´ees. Ce d´esert a rendu la tˆache ardue mais attractive et concr`ete. On
va montrer dans la suite de ce document comment nous allons essayer de
construire un point d’eau dans ce d´esert.
2 Motivations
2.1 Les d´ etracteurs
De nombreux langages objets, comme C++, Eiffel ou C#, proposent la sur-
charge d’op´erateurs. Mais Java n’impl´emente pas cette fonctionnalit´e. Nous
nous sommes demand´e pourquoi, et la raison qui semble ressortir est le souci
de simplicit´e [2]:
Java omits many rarely used, poorly understood, confusing
features of C++ that in our experience bring more grief than be-
nefit. These omitted features primarily consist of operator over-
loading (also the Java language does have method overloading),
multiple inheritance, and extensive automatic coercions.
Mais `a quel prix? C’est un vieux d´ebat de l’informatique: simplicit´e contre
expressivit´e. Guy Steele [3] apporte sa solution : l’´evolutivit´e d’un langage, et
qualifie Java de langage ´evolutif.
2

Alors, si cette ´evolutivit´e permettrait d’apporter `a Java la surcharge d’op´erateurs,
pourquoi ne pas le faire? Certains r´epondrait:
– “Si Sun ne l’a pas fait, c’est que ce n’est pas une bonne chose ou que
c’est impossible!”. Nos lectures pendant la pr´eparation de ce rapport
nous ont appris `a d´emythifier Sun, et `a voir les programmeurs humains
derri`ere ce sigle (on fera r´ef´erence surtout `a [4], qui pr´esente les prin-
cipaux d´efauts, selon l’auteur, de Java). De plus, si Java se dit ´evolutif,
c’est bien pour le faire ´evoluer !
– “La surcharge d’op´erateurs est un luxe dont on peut se passer.”. Alors,
`a l’extrˆeme, pourquoi ne pas programmer en assembleur?
– En ce qui concerne l’´eternelle “illisibilit´e” que provoquerait la sur-
charge d’op´erateurs, nous pensons que cet argument n’est pas rece-
vable: mˆeme James Gosling [5], pourtant au d´ebut oppos´e `a la sur-
charge d’op´erateurs, avoue :
And if you look at people who are doing complex arthmetic
in Java right now, it’s really ugly. I mean, it’s unbelievably
ugly.
– “Un programmeur peut d´efinir des op´erateurs avec une s´emantique bi-
zarre, non-intuitive.”. Nous nous joignons `a Conrad Weisert [6] pour
r´epondre:
Any programmer so undisciplined as to define + to do sub-
straction is likely also to define add in the same misleading
way or to commit all sorts of other programming sins. Com-
petent professionals are unlikely to do either.
2.2 L’int´ erˆ et
Le succ´es de Java est certes important, mais il y a une cat´egorie de pro-
grammeurs qu’il n’a pas conquis: les math´ematiciens et tous ceux qui uti-
lisent l’informatique `a des fins majoritairement num´erique. Ces personnes
reprochent `a Java sa lourdeur d’´ecriture et son manque d’efficacit´e `a ce ni-
veau. Un exemple souvent cit´e est l’utilisation des nombres complexes : on
aimerait, pour ce type d’objet num´erique, jouir des mˆemes avantages que les
types primitifs, c’est `a dire efficacit´e, utilisation des op´erateurs arithm´etiques
et s´emantique par copie. Ainsi, nos recherches nous ont pratiquement toujours
ramen´e `a ce mˆeme th`eme: l’extension de Java au niveau num´erique. On citera
par exemple le projet JavaGrande [7], qui propose une approche int´eressante
que nous d´evelopperons dans la section 4.
Le num´erique semble donc ˆetre le talon d’achille de Java, et la surcharge
des op´erateurs serait un pas en avant vers un Java plus universel.
3

3 Les impl´ ementations existantes
Durant nos travaux de recherche pr´eliminaires, nous avons rencontr´e deux
approches bien distinctes. Tout d’abord, celle qui consiste `a faire passer un
pr´e-processeur sur le code et faire un remplacement textuel des op´erateurs
par les m´ethodes correspondantes, et une autre, plus subtile, qui consiste `a
introduire un nouveau type, pseudo-primitif, qui conserverait une s´emantique
de passage par valeur et certaines propri´et´es des “classes lourdes”.
3.1 Les pr´ eprocesseurs
C’est le moyen le plus simple et le plus intuitif d’impl´ementer la surcharge
d’op´erateurs. Dans les d´efinitions des classes, on impl´emente les m´ethodes
surchargeant les op´erateurs en leur donnant une syntaxe bien particuli`ere. En-
suite, une fois notre programme principal ´ecrit, on fait passer un pr´eprocesseur
qui se charge de remplacer textuellement les op´erateurs par les appels de
m´ethodes correspondants. C’est une approche purement syntaxique pour la-
quelle nous n’avons trouv´e que peu d’exemples. L’un d’entre eux, JFRONT
d´efinit ses classes comme ceci (par exemple la classe ) :
4

Apr´es passage du pr´eprocesseur, on obtient le source suivant:
Nous avons ´egalement pu observer une autre approche, qui consiste `a in-
troduire un nouveau type, pseudo-primitif, pour lequel on pourrait surcharger
les op´erateurs.
3.2 Un type pseudo-primitif
Il existe deux sortes de types en Java, les classes qui ont une s´emantique
par r´ef´erence, et les types primitifs qui ont une s´emantique par copie. L’id´ee
est d’offrir `a l’utilisateur un nouveau type, orient´e num´erique qui conserverait
un peu des propri´et´es des deux pr´ec´edents. Cette id´ee est lanc´ee par Bill Joy
[8]et est reprise par , qui est une extension du langage Java ´ecrite par
Joseph D. Darcy [9].
Si l’utilisateur d´efinit un nouveau type arithm´etique, alors il est d´esirable
que celui-ci ait une s´emantique par copie, c’est `a dire analogue `a celle des
types primitifs. De mˆeme, on aimerait conserver la notation infixe propre aux
math´ematiciens, d’ou la necessit´e de pouvoir surcharger les op´erateurs.
Borneo introduit un nouveau mot-cl´e, qui agit comme un modifica-
teur de classe. Seules les classes d´eclar´ees comme peuvent d´efinir des
m´ethodes permettant la surcharge d’op´erateurs. De plus, pour pouvoir per-
mettre `a ces classes de se comporter comme des types primitifs, ini-
tialise par d´efaut tous les champs de ces classes.
4 Notre approche
L’approche que nous allons pr´esenter ici est celle qui nous semble au-
jourd’hui la plus int´eressante : c’est celle qui consiste `a introduire un type
pseudo-primitif. Elle est ax´ee principalement sur l’extention de Java au ni-
veau num´erique, et s’appuie sur les propositions de JavaGrande [7], ainsi que
sur l’impl´ementation existante Borneo [9].
5