Project

General

Profile

Évolution #1505

Classe VersionNumber implémentant les spécifications du Versionnement Sémantique

Added by Skalp almost 8 years ago. Updated over 7 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
Category:
Fonctionnalités
Target version:
Start date:
03/31/2012
Due date:
% Done:

100%

Estimated time:
10.00 h
Spent time:

Description

- Développement de la classe VersionNumber implémentant les spécifications du Versionnement Sémantique (http://semver.org)
- Développement de tests unitaires automatisés correspondant aux différentes fonctionnalités.

History

#1 Updated by Skalp almost 8 years ago

  • % Done changed from 0 to 100

#2 Updated by Skalp almost 8 years ago

  • Status changed from Nouveau to Résolu

#3 Updated by Skalp almost 8 years ago

  • Status changed from Résolu to Fermé

#4 Updated by tomlev almost 8 years ago

Ils passent pas tes tests unitaires ^^

Enfin, y en a un qui passe pas chez moi : GetHashCodeTest. Tu ne peux pas supposer que GetHashCode renverra toujours la même valeur d'une version à l'autre du framework, il n'y a absolument aucune garantie à ce sujet (et d'ailleurs en pratique les implémentations de GetHashCode pour certains types, dont String, changent d'une version à l'autre)

#5 Updated by tomlev almost 8 years ago

  • Status changed from Fermé to Assigné

Réouvert pour correction du bug mentionné plus haut ;)

Au fait, ne ferme pas tout de suite les demandes que tu as traitées, mets les en Résolu. On les passera en Fermé à la prochaine release

#6 Updated by tomlev almost 8 years ago

En attendant tes corrections, j'ai désactivé ce test ([Ignored]) parce que ça m'énervait d'avoir un test "failed" à chaque fois ;)

Au passage, j'ai remarqué le test GetHashCodeUnicityTest : un hashcode n'est pas un identifiant unique, rien ne garantit que 2 instances différentes de VersionNumber donneront un hashcode différent. La seule contrainte, et la seule chose à vérifier, c'est que instances identiques de VersionNumber donnent bien le même hashcode. Autrement dit, si x.Equals(y) est true, alors x.GetHashCode() et y.GetHashCode() sont égaux, mais la réciproque n'est pas nécessairement vrai : les collisions de hashcode sont tout à fait permises. Ce test n'a donc pas de sens, il faut le supprimer (et éventuellement le remplacer par un autre plus adéquat)

#7 Updated by Skalp almost 8 years ago

Mince, j'avais pas vu tous tes messages. J'avais vu seulement : "Au fait, ne ferme pas tout de suite les demandes que tu as traitées, mets les en Résolu. On les passera en Fermé à la prochaine release;".
Elle a du te paraître bizarre ma réponse, non ? :P

Je n'ai toujours pas bien compris l'utilité des hashcode : j'ai lu (en plus des remarques que tu donnes) que moins il y a de collisions, plus les opérations qui utilisent ces hashcodes seront rapides. C'est pour ça que j'ai développé un truc comme ça.

Comment tu vois le truc, toi ? Est-ce qu'on pourrait utiliser la méthode d'extension que tu as créé dans CoreExtension ? Et pour les tests unitaires ?

#8 Updated by tomlev almost 8 years ago

Effectivement, il faut essayer d'avoir le moins possible de collisions (d'où les manips avec des nombres premiers pour obtenir la meilleure distribution possible), mais on ne peut pas les éviter complètement, puisque il y a potentiellement plus d'instances différentes de VersionNumber que de valeurs possibles de int. A partir du moment où ce n'est pas possible de les éviter complètement, ça n'a pas de sens de tester que ça n'arrive jamais. D'ailleurs, vu que ça dépend aussi des hashcodes de int et string sur lesquels on n'a pas de contrôle, il se pourrait tout à fait qu'on ait des collisions sur certaines versions du CLR et pas sur d'autres...

De toutes façons, ton implémentation de GetHashCode est correcte. On pourrait utiliser la méthode d'extension MakeHashCode, mais ça n'apporterait pas grand chose et ce serait moins performant.

Pour les tests, comme je disais, il y a une seule chose à tester en ce qui concerne le hashcode : que deux instances considérées comme identiques (d'après Equals) renvoient bien le même hashcode.

Sinon, j'ai apporté quelques modifs à ta classe, principalement des corrections de warnings R#, et des micro-améliorations

#9 Updated by tomlev almost 8 years ago

Ah oui, un dernier truc : ce serait mieux de rendre la classe immuable, comme la classe Version du framework, donc mettre les propriétés en lecture seule avec des champs readonly derrière. Conceptuellement, c'est plus logique, car un numéro de version a une sémantique de valeur (ça pourrait d'ailleurs éventuellement être une structure, mais là encore, autant faire comme la classe Version du framework...)

#10 Updated by tomlev almost 8 years ago

Bon, j'aime pas laisser trainer alors j'ai corrigé moi-même ;)
J'ai aussi rendu la classe immuable.

#11 Updated by tomlev almost 8 years ago

  • Status changed from Assigné to Résolu

#12 Updated by tomlev over 7 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF