Discussion :

[lequebecois79]

bonjour

je désire créer une date a partir d'une semaine et d'une année.

Code :

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

1
2
3
4
5
6
 
            DateTime dt = new DateTime();
            dt.withWeekyear(29);
            dt.withYear(2011);
 
             System.out.println("dt " +  dt.getWeekOfWeekyear() + " " + dt.getYear());

avec ce code j'obtiens à l'affichage: 16 2012 soit les la semaine et l'année en cours

comment faire pour obtenir 29 2011?

une idée?

[Népomucène]

Ouh là là le petit coquin qui n'a pas lut la doc !

Dans la doc il est écrit que DateTime est un objet immuable.
Immuable ça veut dire qu'on ne peut pas changer .. eh oui !

donc : inutile d'essayer de lui modifier sa semaine ou son année.
Ada Lovelace, David Hilbert, Alan Turing et John von Neumann n'ont pas voulu essayer ... c'est dire la difficulté !

En revanche, dans sa grande bonté, le Dieu Joda a prévu une autre classe : MutableDateTime
Ce qui nous donne :

Code :

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

1
2
3
4
5
            MutableDateTime dt = new MutableDateTime();
            dt.setWeekOfWeekyear(29);
            dt.setYear(2011);
 
             System.out.println("dt " +  dt.getWeekOfWeekyear() + " " + dt.getYear());

et tu obtiens bien :

dt 29 2011

Voilà, c'était la déconnade du samedi.

Bon, allez @lequebecois79 c'est pas grave, moi aussi j'avais pas mal cherché pourquoi
mon DateTime ne bougeais pas avant de trouver l'existence de l'autre classe !

Et je ne vois pas bien pourquoi Joda a créé une classe immuable et l'autre non.

[thelvin]

Et je ne vois pas bien pourquoi Joda a créé une classe immuable et l'autre non.

Parce qu'une date, c'est une date, c'est pas mardi à un moment et lundi trois appels de méthodes plus tard. Une date ça sert à indexer des Map, ou à être gardé comme collection dans un Set.
Et ces machins-là, ça doit être immutable.

Mais n'avoir que des objets immutables, c'est emmerdant quand on a besoin de construire sur un calendrier dont on change tout le temps les données : créer soixante nouveaux objets DateTime à chaque fois qu'on veut en garder trois, c'est pas terrible terrible. Pour ce cas-là, ont été ajoutées les versions mutables. À utiliser pour construire les immutables.

[Népomucène]

Parce qu'une date, c'est une date, c'est pas mardi à un moment et lundi trois appels de méthodes plus tard

moui, moui, moui ... certes, bien sûr.

Je vais faire un parallèle avec les dates que j'utilise dans mes bases de données.
Les dates de factures, d'écritures comptables, etc sont stockées dans des champs colonnes(*) de type "DateTime".
Ces dates sont toutes modifiables avec l'instruction "UPDATE ..." donc pas de blocage du point de vue du SGBD.

Mais je vais bien sûr ajouter le verrouillage qui va bien (Trigger, vérification dans l'application client, etc.)
pour que mes dates de factures ne soient jamais modifiées une fois que le document a été validé.
Le même outil de programmation (champ date) me sert donc indifféremment pour des dates modifiables ou non.

Donc je continue de penser qu'il aurait été possible de faire avec une seule classe mutable.



(*) il faut utiliser le mot colonnes sinon notre ami SqlPro va me faire les gros yeux

[thelvin]

Oui, une BDD est rarement en lecture seule pour absolument tout le monde. Pas seulement les dates, on peut aussi mettre à jour les entiers et les textes. Integer et String sont pourtant immutables.

Une BDD est un stockage, pas un espace de programmation. Du moins en principe, et puis même quand on programme une BDD, les données volatiles et l'espace de stockage durable sont deux choses différentes qui n'ont aucun lien l'une avec l'autre.

C'est comme je l'ai dit : une date doit être immutable, parce qu'une date on s'en sert pour indexer des Map ou les collectionner dans un Set. Or ce qu'on utilise pour ça doit être immutable. Puisque ça ne doit pas muter.

Donc je continue de penser qu'il aurait été possible de faire avec une seule classe mutable.

Bien sûr que ça aurait été possible, c'est d'ailleurs ce que fait Java de base : java.util.Date est mutable. (Bon, ça ne permet pourtant pas de construire une Date correctement. Pour ça il faut un Calendar. java.util.Date a plusieurs défauts de conception, dont celui-ci.)
Il est possible de le faire, simplement il ne faut pas le faire.

[Népomucène]

Il est possible de le faire, simplement il ne faut pas le faire

ça c'est une belle expression, élégante, qui exprime bien pourquoi il faut de la rigueur dans la conception.
(exemple d'absence de rigueur pour moi : ne rien mettre rien dans les catchs des exceptions !)

Bon, naturellement, je suis d'accord avec toi sur le but final de l'opération :
une fois qu'on a placé une date dans une map ou une table de SBGD alors ça ne doit plus bouger.

Mais comme j'ai l'habitude de décider moi-même de ce qui bouge ou pas ...
Je suis probablement susceptible mais DateTime immuable pour moi c'était un peu
comme si Joda me disait : "écoute petit, comme tu ne sais pas programmer, je vais te bloquer de ce côté là ..."

Bon, @thelvin merci pour ton avis (rigoureux) sur lequel je vais méditer (à partir de lundi)
maintenant il faut que je réfléchisse pour qui je vais voter demain

bonne soirée à tous