From: "Laurent Delaforge" <ldelaforgefr@aol.com>
To: "java strasbg" <java@u-strasbg.fr>
Subject: Protegeons les parametres !
Date sent: Thu, 6 Sep 2001 12:55:57 +0200
Send reply to: java@u-strasbg.fr
Bonjour,
Pourquoi n'est-il pas possible d'empecher un parametre d'etre modifie ?
(equivalent au 'const' en c++)
Notes :
- J'entends par 'modifier', changer un attribut de l'instance :
f(A a)
{
A b;
a.attribut = newValue;
}
et non l'instance elle meme :
f(A a)
{
A b;
a=b;
}
- J'ai essaye avec final : f(final A a)
çà empeche de modifier l'instance elle-même, mais on peut toujours
modifier les attributs
J'ai lu dans Thinking In Java :
"All argument passing in Java is performed by passing references. That is,
when you pass “an object,” you’re really passing only a reference to an
object that lives outside the method, so if you perform any modifications
with that reference, you modify the outside object. In addition:
...
a.. There is no language support (e.g., “const”) to prevent objects from
being modified (that is, to prevent the negative effects of aliasing)."
mais je ne comprend comment l'aliasing peut poser probleme lorsqu'on
empeche un parametre d'etre modifie...
quelqu'un aurait-il les reponses à mes questions existentielles ?
From: ROUSSEL Yohann <yohann.roussel@criltelecom.com>
To: "'java@u-strasbg.fr'" <java@u-strasbg.fr>
Subject: RE: Protegeons les parametres !
Date sent: Thu, 6 Sep 2001 13:46:05 +0200
Send reply to: java@u-strasbg.fr
Pour ce qui est de proteger un objet que tu vas passer en parametre, en
JAVA tu n'as, a ma connaissance, que 2 possibilites : soit tu fais (a ta
facon) une copie de l'objet que tu vas passer en parametre. Soit tu
définis un objet impossible a modifier (ex String) et c'est ca que tu
passe tu passes en parametre de ta methode
-----Message d'origine-----
De : Laurent Delaforge [mailto:ldelaforgefr@aol.com]
Envoyé : jeudi 6 septembre 2001 12:56
À : java strasbg
Objet : Protegeons les parametres !
Bonjour,
Pourquoi n'est-il pas possible d'empecher un parametre d'etre modifie ?
(equivalent au 'const' en c++)
Notes :
- J'entends par 'modifier', changer un attribut de l'instance :
f(A a)
{
A b;
a.attribut = newValue;
}
et non l'instance elle meme :
f(A a)
{
A b;
a=b;
}
- J'ai essaye avec final : f(final A a)
çà empeche de modifier l'instance elle-même, mais on peut toujours
modifier les attributs
J'ai lu dans Thinking In Java :
"All argument passing in Java is performed by passing references. That is,
when you pass "an object," you're really passing only a reference to an
object that lives outside the method, so if you perform any modifications
with that reference, you modify the outside object. In addition:
...
* There is no language support (e.g., "const") to prevent objects from
being modified (that is, to prevent the negative effects of aliasing)."
mais je ne comprend comment l'aliasing peut poser probleme lorsqu'on
empeche un parametre d'etre modifie...
quelqu'un aurait-il les reponses à mes questions existentielles ?
From: "Laurent Delaforge" <ldelaforgefr@aol.com>
To: <java@u-strasbg.fr>
Subject: RE: Protegeons les parametres !
Date sent: Thu, 6 Sep 2001 14:04:46 +0200
Send reply to: java@u-strasbg.fr
En fait, je cherche plutot à comprendre "pourquoi" l'equivalent des
'const' n'existe pas en java.
(Meme si, je suis tout a fait d'accord, le probleme se contourne en
clonant l'objet ou en utilisant un objet 'immutable'.)
-----Original Message-----
From: ROUSSEL Yohann [mailto:yohann.roussel@criltelecom.com]
Sent: Thursday, September 06, 2001 1:46 PM
To: 'java@u-strasbg.fr'
Subject: RE: Protegeons les parametres !
Pour ce qui est de proteger un objet que tu vas passer en parametre, en
JAVA tu n'as, a ma connaissance, que 2 possibilites : soit tu fais (a ta
facon) une copie de l'objet que tu vas passer en parametre. Soit tu
définis un objet impossible a modifier (ex String) et c'est ca que tu
passe tu passes en parametre de ta methode
-----Message d'origine-----
De : Laurent Delaforge [mailto:ldelaforgefr@aol.com]
Envoyé : jeudi 6 septembre 2001 12:56
À : java strasbg
Objet : Protegeons les parametres !
Bonjour,
Pourquoi n'est-il pas possible d'empecher un parametre d'etre modifie
?
(equivalent au 'const' en c++)
Notes :
- J'entends par 'modifier', changer un attribut de l'instance :
f(A a)
{
A b;
a.attribut = newValue;
}
et non l'instance elle meme :
f(A a)
{
A b;
a=b;
}
- J'ai essaye avec final : f(final A a)
çà empeche de modifier l'instance elle-même, mais on peut toujours
modifier les attributs
J'ai lu dans Thinking In Java :
"All argument passing in Java is performed by passing references. That
is, when you pass “an object,” you’re really passing only a reference to
an object that lives outside the method, so if you perform any
modifications with that reference, you modify the outside object. In
addition:
...
a.. There is no language support (e.g., “const”) to prevent objects
from
being modified (that is, to prevent the negative effects of aliasing)."
mais je ne comprend comment l'aliasing peut poser probleme lorsqu'on
empeche un parametre d'etre modifie...
quelqu'un aurait-il les reponses à mes questions existentielles ?
From: "Erik Mazoyer" <erik.mazoyer@laposte.net>
To: <java@u-strasbg.fr>
Subject: Re: Protegeons les parametres !
Date sent: Thu, 6 Sep 2001 14:41:17 +0200
Send reply to: java@u-strasbg.fr
C'est un choix de langage.
J'ai longtemps travaillé en C++ avant de passer à java.
const est génial mais à parfois de limitation.
Par exemple, on possède une classe Point qui supporte 2 représentation : -
x,y - angle,rayon
Par défaut on ne possède qu'une représentation (par exemple x,y)
quand quelqu'un demande l'angle, on le calcul, on le stocke (pour éviter
un recalcule) et on le renvoie.
du coup, la méthode
double getAngle()
ne peut pas être const (il y a modification d'un champ de l'objet) même si
sémantiquement l'objet n'a pas changé
Alors on introduit des bizarrerie
maClasse objet = (maClasse)this;
ce qui permet de caster un "const maClasse" en "maClasse" et donc de
pouvoir modifier un champs même si this est const !!!
Maintenant en Java, l'approche peut être différente, grâce aux interfaces.
Quand je rencontre ton problème, je déclare une interface :
maClasseAccesseur
public interface maClasseAccesseur {
public double getAngle();
}
Puis je déclare ma classe
public class maClasse implements maClasseAccesseur {
public double getAngle() {
...
}
...
}
Quand j'ai besoin d'un objet en consultation, je donne l'objet sous forme
de maClasseAccesseur.
Cordialement,
----------------------------------------
Erik Mazoyer
erik.mazoyer@laposte.net
----- Original Message -----
From: Laurent Delaforge
To: java@u-strasbg.fr
Sent: Thursday, September 06, 2001 2:04 PM
Subject: RE: Protegeons les parametres !
----------
De : Laurent Delaforge[SMTP:LDELAFORGEFR@AOL.COM]
Envoyé le : jeudi 6 septembre 2001 14:04:46
A : java@u-strasbg.fr
Objet : RE: Protegeons les parametres !
Transféré automatiquement par une règle
En fait, je cherche plutot à comprendre "pourquoi" l'equivalent des
'const' n'existe pas en java.
(Meme si, je suis tout a fait d'accord, le probleme se contourne en
clonant l'objet ou en utilisant un objet 'immutable'.)
-----Original Message-----
From: ROUSSEL Yohann [mailto:yohann.roussel@criltelecom.com]
Sent: Thursday, September 06, 2001 1:46 PM
To: 'java@u-strasbg.fr'
Subject: RE: Protegeons les parametres !
Pour ce qui est de proteger un objet que tu vas passer en parametre,
en JAVA tu n'as, a ma connaissance, que 2 possibilites : soit tu fais
(a ta facon) une copie de l'objet que tu vas passer en parametre. Soit
tu définis un objet impossible a modifier (ex String) et c'est ca que
tu passe tu passes en parametre de ta methode
-----Message d'origine-----
De : Laurent Delaforge [mailto:ldelaforgefr@aol.com]
Envoyé : jeudi 6 septembre 2001 12:56
À : java strasbg
Objet : Protegeons les parametres !
Bonjour,
Pourquoi n'est-il pas possible d'empecher un parametre d'etre
modifie ? (equivalent au 'const' en c++)
Notes :
- J'entends par 'modifier', changer un attribut de l'instance :
f(A a)
{
A b;
a.attribut = newValue;
}
et non l'instance elle meme :
f(A a)
{
A b;
a=b;
}
- J'ai essaye avec final : f(final A a)
çà empeche de modifier l'instance elle-même, mais on peut
toujours modifier les attributs
J'ai lu dans Thinking In Java :
"All argument passing in Java is performed by passing references.
That is, when you pass "an object," you're really passing only a
reference to an object that lives outside the method, so if you
perform any modifications with that reference, you modify the
outside object. In addition:
...
a.. There is no language support (e.g., "const") to prevent objects
from being modified (that is, to prevent the negative effects of
aliasing)."
mais je ne comprend comment l'aliasing peut poser probleme lorsqu'on
empeche un parametre d'etre modifie...
quelqu'un aurait-il les reponses à mes questions existentielles ?
Date sent: Thu, 06 Sep 2001 15:25:42 +0200
From: Eric Lepicier <lepicier@shom.fr>
To: java@u-strasbg.fr
Subject: Re: Protegeons les parametres !
Send reply to: java@u-strasbg.fr
Bonjour,
Dans le meme ordre d'idee que celle d'Erik :
Java offre pour ses collections des classes non modifiables ...
Voir dans la classe Collections :
static Collection unmodifiableCollection(Collection c)
Returns an unmodifiable view of the specified collection.
static List unmodifiableList(List list)
Returns an unmodifiable view of the specified list.
static Map unmodifiableMap(Map m)
Returns an unmodifiable view of the specified map.
.. etc
La collection non modifiable retournee par ces methodes est une
sous-classe
de la collection originale dans laquelle les methodes "non const"
sont surchargees pour jeter une UnsupportedOperationException.
Les sous-classes sont ecrites comme des inner-classes de leur equivalent
modifiable. Tu n'est pas oblige d'implementer ca sous forme de factory,
mais ca peut etre interessant dans ton cas de reprendre ce mecanisme.
ERIC
--
__"__ Email from a friend: "CanYouFixTheSpaceBarOnMyKeyboard?"
(_.)_.)
-ooOO--(_)--OOoo---- Eric LEPICIER - EPSHOM / BREST / FRANCE
----------------
From: "Cedric Beust" <cedric@beust.com>
To: <java@u-strasbg.fr>
Subject: RE: Protegeons les parametres !
Date sent: Thu, 6 Sep 2001 08:22:33 -0700
Send reply to: java@u-strasbg.fr
From: Erik Mazoyer [mailto:erik.mazoyer@laposte.net]
C'est un choix de langage.
J'ai longtemps travaillé en C++ avant de passer à java.
const est génial mais à parfois de limitation.
Par exemple, on possède une classe Point qui supporte 2 représentation :
- x,y - angle,rayon
Par défaut on ne possède qu'une représentation (par exemple x,y)
quand quelqu'un demande l'angle, on le calcul, on le stocke (pour éviter
un recalcule) et on le renvoie.
du coup, la méthode
double getAngle()
ne peut pas être const (il y a modification d'un champ de l'objet) même
si
sémantiquement l'objet n'a pas changé
Alors on introduit des bizarrerie
maClasse objet = (maClasse)this;
ce qui permet de caster un "const maClasse" en "maClasse" et donc de
pouvoir modifier un champs même si this est const !!! En fait, pour cet
exemple precis, tu peux utiliser un mot-cle de C++ (mutable). Tu peux
aussi utiliser un const_cast.
Pour repondre au posteur initial, il n'y a pas de reponses claires,
plusieurs hypotheses ont ete avancees. Pour avoir travaille' egalement en
C++ et const, je dois dire que si l'idee est bonne a la base,
l'implementation en C++ se transforme assez souvent en ensemble de classes
tres rigides ("Midas Effect": si tu declares un objet const, cette
propriete va se propager a ses accesseurs, etc... et tu finis avec pas mal
de const_cast dans ton code).
Ce n'est pas une fonctionnalite qui me manque particulierement en Java.
--
Cedric