Discussion :

[g_rare]

Bonjour,

Je viens d'envoyer un mail aux gens de chez Jakarta Commons Lang pour leur demander pourquoi ne pas intégrer une interface Immutable vide (sans méthode), servant à marquer avec certitude quelles sont les classes qui "déclarent respecter ce contrat" (impossible à déterminer par introspection) : en effet une RFE [Request For Enhancement] officielle existe depuis 2001 mais pour l'instant pas de conclusion chez Sun.
Bref voici le mail en question puis la réponse (désolé pour mon anglais)...

Hello,

I'm very surprised not to find any org.commons.immutable.Immutable empty
interface (as java.lang.Cloneable do) : neither into the actual version of
Commons Lang, nor into the TODO list. If there's any reason for that lack
?
I officially suggest you to add it... waiting for an official decision
about the Sun request
http://bugs.sun.com/bugdatabase/view...bug_id=4617197 !

NB_ I think it could be a good idea, into the class Javadoc of this new
no-method Immutable interface, to say that it is only a declarative
interface and to add any precision about what are the real requirements it
implies (final class, private attributes, no setters, getters returning
copies...)

Thancks to say if I'm totally wrong :-)

cordially

It's best to send such questions to commons-dev@jakarta.apache.org
(usually after subscribing first
'commons-dev-subscribe@jakarta.apache.org'), or to add them to the
JIRA instance (http://issues.apache.org/jira/browse/LANG).

There's not an Immutable interface because Lang aims not to force
religion (for use of a better word) on the developer. There are very,
very few interfaces in Lang and neither of them need to be implemented
by developers to get functionality.

There's also not a lot of concrete value in marker interfaces,
Cloneable is a bad example as along with Serializable it should have
had the methods declared in it instead of linking to JVM magic. So
that's another reason for no marker interfaces in Lang - we can't do
the JVM magic.

Bref est-ce vraiment une si mauvaise idée de faire confiance aux développeurs à propos d'une propriété de classe "quasiment indémontrable" autrement que de manière déclarative ?
J'en appelle à vos avis d'experts!

MERCI D'AVANCE

[Baptiste Wicht]

Personnellement, j'estime qu'une classe immuable doit le préciser dans sa documentation et que c'est suffisant pour l'indiquer. On ne devrait pas faire des tests dans notre programme en fonction de l'immuabilité d'une classe.

[g_rare]

Quid des classes (comme par exemple un Generic DAO) dont les méthodes attendent des objets immuables en paramètre :
- la signature "methode(final Object parametre)" ne protège que d'une réaffectation en interne,
- la signature "methode(final Cloenable parametre)" duplique les references vers les attributs si on effectue un clone en interne,
- la signature "methode(final Serializable parametre)" ne permet pas de faire une <<deep copy>> en interne en cas de référence circulaire dans les paramètres.

Donc la signature "methode(final Immutable parametre)" prendrait tout son sens afin de lutter contre tous les effets de bord potentiels ?!
Si jamais d'autres pistes existent...

[Baptiste Wicht]

Le problème avec des telles interfaces, c'est qu'il suffit de déclarer sa classe Immutable pour qu'elle le soit. N'importe qui pourrait utiliser cette interface pour une classe pas tout à fait immuable et ensuite tu te baserais là-dessus, alors que c'est faux. Tu peux aussi avoir une classe immuable qui change pour devenir muable mais qui implémente toujours Immutable.

Dans les apis de qualité, je pense qu'il suffit que figure dans la javadoc de la classe qu'elle est immuable.

Dans les deux cas, il faudra faire confiance aux developpeurs, donc je ne vois pas trop ce que ça peut apporter.

[*alexandre*]

un développeur doit s'assurer que son objet ne va pas évolué avant et après un appel de méthode moi je trouve ca débile

[bouye]

A ce niveau la mieux faut demander l'integration du mot-cle const (different de final) pour faire comme en C++ et indiquer la mutabilite d'un objet en parametre ou en retour de methode et si une methode influe sur la mutabilite de l'objet...

Code C++ :

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
 
class Bidule {
private:
const Machin* m_machin;
 
public:
  Bidule(const Machin machin&) {
    m_machin = &machin;
  }
 
  const Machin* getMachin() const {
     return m_machin;
  }
 
  void setMachin(const Machin machin&) {
     m_machin = &machin;
  }
};

Enfin, euh, si mon C++ n'est pas trop rouille (moi = tete vide en ce moment). Par exemple la methode setMachin() ne peut pas etre appelee sur des types non-mutables de la classe Bidule (Bidule, Bidule*, Bidule& sont mutable alors que const Bidule, const Bidule* et const Bidule& ne le sont pas). Ensuite les types de retour et de parametre sont forces a etre inmutables egalement (oui l'exemple est un peu stupide).

Enfin, sauf si on force le cast bien sur.

Evidement tout de suite ca allourdi un peu le language (mais bon en ces periodes de sur-usage d'annotations a tout va...).

[gifffftane]

Moi je trouve que cela serait une bonne idée, car les classes immuables jouent des rôles particulier dans un programme (clefs, sécurité, etc...).

Cependant, dans l'état actuel des choses, c'est surtout une question de bone volonté du programmeur, et de documentation. De ce coté là l'ajout d'une interface n'ajouterait grand chose : je ne vois pas comment on pourrait empecher un programmeur de faire une fausse classe immuable.

Si l'on voulait aller plus loin, il me semble qu'il faudrait en passer par une prise en charge de la notion d'aggrégation. En effet, immuable, cela veut dire, il me semble Que mes composants ne changent pas. C'est la notion Tel objet appartient à tel autre. Cela n'existe pas actuellement.

Mais comme le compilateur a été libéré, peut être pourrais-tu le faire ?...