Version imprimable
Bon voila, j'ai une question simple, (je te l'ai envoyé en mail, mais ça peut intéresser du monde).
Est-ce que les generics Java sont supportés lors d'un reverse?
Par exemple, si j'ai le code :
... est-ce que le reverse va me retrouver une relation (1..n) entre la classe Magasin et Film ?Citation:
public class Magasin {
private ArrayList<Film> films = new ArrayList<Film>();}
J'ai pas l'impression que ça marche malheureusement... ou bien je m'y prends mal ??
Absolument, et ce depuis la version 2.14.4Citation:
Envoyé par pomauguet
le reverse ne cree pas une relation mais l'attribut films de type ArrayList<Film>Citation:
Envoyé par pomauguet
ceci est tout a fait légal, et si on genere le code a partir du modele obtenu on retrouve le code d'origine
Ceci dit je comprends que tu aurais préféré une relation vers Film avec le stereotype ArrayList (ou un equivalent produisant ArrayList en Java via les generation settings), c'est a dire ce que fait très bien le reverse C++.
J'avoue donc avoir été un peu 'faineant' de ce coté lors de l'ajout des generics, mais bon, ce n'est sans doute que partie remise !
Par contre il n'y a aucune chance que le reverse donne une multiplicite de 1..n car il n'y a aucun moyen de savoir cela, la multiplicite est donc laissée vide par le reverse (C++ compris)
c'est l'eternel probleme de la compatibilite, comment savoir ce qui est utilise ? je prefere proposer quelque chose qui marche certainement plutot que quelque chose qui demande trop en terme de version javaCitation:
Envoyé par pomauguet par mail
bonnes modelisations
Oui, je confirme, ça serait vraiment du bonheur d'avoir la relation plutôt que l'attribut :mouarf:Citation:
Envoyé par bruno_pages
Ca me surprend. Si j'utilise une ArrayList ou un tableau pour un attribut de classe, c'est bien que j'attends une variable éventuellement multivaluée.Citation:
Envoyé par bruno_pages
Dans ce cas, l'outil peut, sans faillir, déduire une cardinalité 0..n (pour faire large). Après, c'est vrai que c'est soit 0..n, soit 1..n, soit une valeur numérique unique (dans des cas très particuliers) mais je pense que l'outil pourrait de prime abord déduire une cardinalité 0..n, quitte ensuite à permettre à l'utilisateur d'écraser la valeur et faire en sorte que cette valeur ne soit pas réécrasée lors d'un nouveau reverse. (bon ok, cette partie sur la préservation de la valeur de la cardinalité mise explicitement par l'utilisateur n'est peut être pas SI évidente à faire ;-))
Je pense différemment. D'une part, il y a un choix par défaut qui, s'il utilisait les ArrayList, pourrait convenir à 99% des gens actuellement (sans exagérer) ; les ArrayList existent depuis le JDK 1.2 et doit dater de 1999. D'un autre côté, certes ça pourrait bloquer les quelques rares personnes qui s'acharneraient à utiliser le JDK 1.1.8, mais alors dans ce cas, pourquoi ce ne serait pas ces rares personnes qui aient à modifier la conf par défaut de la génération (et mette Vector), plutôt que l'inverse?Citation:
... les ArrayList ont remplacé les Vector en Java ...
c'est l'eternel probleme de la compatibilite, comment savoir ce qui est utilise ? je prefere proposer quelque chose qui marche certainement plutot que quelque chose qui demande trop en terme de version java
[Ca me fait penser à ces applis web qu'on m'imposait de faire en résolution 800x600. L'argument était acceptable en 2000, mais qu'on me fasse les mêmes remarques en 2005, là je commençais à ne plus être d'accord.
On peut laisser un certain temps de latence, mais au bout d'un moment, il faut un peu forcer les choses, quitte à imposer un choix à une minorité. Sinon l'informatique continue à évoluer, et on se retrouve à utiliser continuellement des outils dépassés... ]
c'est déjà suffisant pour ne rien faire, de plus en le laissant vide l'utilisateur voit plus facilement qu'il a a faire quelque chose ;)Citation:
Envoyé par pomauguet
aucune de chance qu'il y est ecrasement : un reverse cree et ne modifie pas, sinon c'est du roundtrip (pas encore dispo sous Bouml)Citation:
Envoyé par pomauguet
encore une fois parce que dans un sens cela produit une erreur, et pas dans l'autre.Citation:
D'une part, il y a un choix par défaut qui, s'il utilisait les ArrayList, pourrait convenir à 99% des gens actuellement (sans exagérer) ; les ArrayList existent depuis le JDK 1.2 et doit dater de 1999. D'un autre côté, certes ça pourrait bloquer les quelques rares personnes qui s'acharneraient à utiliser le JDK 1.1.8, mais alors dans ce cas, pourquoi ce ne serait pas ces rares personnes qui aient à modifier la conf par défaut de la génération (et mette Vector), plutôt que l'inverse?
D'autre part pour tes 99% : personnellement j'ai une vieille jdk sans les generics (pour etre sure de ne pas utiliser du trop neuf cote Java lors de mes essais), et par exemple mon collegue de bureau ne veut pas en entendre parle, donc 100% sans ;)
Bonjour,
j'ai amélioré le reverse dans la version 2.25.1 pour qu'il ne produise plus systématiquement des attributs lorsque le type est un générique mais, autant que faire ce peut, des relationsCitation:
Envoyé par pomauguet
bonnes modélisations
Merci Bruno. J'ai testé ça ce we et ça marche parfaitement ! :D