Overloads Function GetHashCode

Bonjour la communauté.

Voilà, j'écris des classes pour des développeurs.
Je souhaitais enlever de l'intellisense les quelques fonctions qui ne sont pas utiliser par les développeurs, et rends l'utilisation des objets moins intuitifs...

Parmi eux : ToString, Equals (..) et GetHAshCode.

Pour les rendre invisible j'ai simplement fait :

Code:

---

1 2 3 4

<System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)> Public Overloads Function GetHashCode() As Integer Return Nothing End Function

---

Problème : Puisque GetHAshCode retourne tout le temps Nothing... On ne peut plus tester si l'objet contient Nothing (pour savoir si l'objet est chargé). Et j'aimerai bien garder cette fonctionnalité.

Question : Que doit on mettre dans cette méthode ? En cherchant sur internet, certains développeurs ont l'air de le réécrire à leur sauce, ce qui ne semble pas toujours propre. Idéalement, moi j'aimerai ne pas la toucher cette méthode, mais la rendre invisible. Quelqu'un aurait il une solution ou une méthode ?

Bonjour mactwist69,

Et ainsi,

Code:

---

1 2 3 4

<System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)> Public Overrides Function GetHashCode() As Integer Return MyBase.GetHashCode() End Function

---

Elle n'est plus visible avec l'intellisense, mais il est toujours possible de l'utiliser. (pas testé au travers d'une dll)
Ou alors j'ai loupé quelque chose dans la question.

Personnellement, je ne pige pas :aie: ; empêcher de voir des méthodes disponibles sur tout les objets juste parce que ... parce que je ne sais pas trop quoi d'ailleurs ; en quoi c'est moins intuitif ?
Par contre les développeurs qui veulent les utiliser eux risquent d'être gênés, ne les voyant pas ils n'auront pas forcément l'idée de les utiliser (alors qu'il suffit de les écrire "manuellement" pour y avoir accès mais encore faut-il le savoir)
Sans parler du fait que cet attribut n'est qu'une indication à l'éditeur qui n'est pas tenu de la respecter (par exemple le plugin Resharper lui s'en fiche et peut-être que SharpDevelop ou Xamarin studio font de même)

Bref tant de "travail" pour potentiellement si peu d'effets et l'obligation de modifier l'implémentation "classique" de la classe (parce qu'a priori s'il n'y avait pas le besoin de cacher ces méthodes elles ne seraient pas surchargées) je ne pige pas :aie:

Citation:

---

Envoyé par mactwist69

Puisque GetHAshCode retourne tout le temps Nothing... On ne peut plus tester si l'objet contient Nothing (pour savoir si l'objet est chargé). Et j'aimerai bien garder cette fonctionnalité.

---

Tu réalises qu'en modifiant ainsi le comportement de GetHashCode les dictionnaires et HashSet qui contiendraient ces objets rameraient comme ce n'est pas permis, ce qui sur un serveur serait une sacrée brèche pour une attaque DDOS ?

Les dictionnaires et HashSet reposent en effet sur GetHashCode avec pour hypothèse que statistiquement les hashes sont bien distribués. C'est ce qui fait que Dictionary.Get ou HashSet.Contains tournent en O(1) et non O(n): pour un hash donné il n'y a en moyenne qu'un élément à inspecter.

Citation:

---

Envoyé par mactwist69

Question : Que doit on mettre dans cette méthode ? En cherchant sur internet, certains développeurs ont l'air de le réécrire à leur sauce, ce qui ne semble pas toujours propre. Idéalement, moi j'aimerai ne pas la toucher cette méthode, mais la rendre invisible. Quelqu'un aurait il une solution ou une méthode ?

---

Les hashes doivent être uniques (dans la mesure du possible), bien distribués et demeurer identiques même si tu changes les champs du type. Ce sont les contraintes que tu dois satisfaire et c'est loin d'être une question simple.

L'implémentation par défaut offre ces garanties pour les classes avec une valeur générée à la création de l'instance. En revanche pour les types valeurs l'implémentation mélange les champs, donc si tu en changes un le hash changera et selon les valeurs que peuvent prendre tes champs le résultat pourrait être mal distribué.

Salut rv26t,

En fait en y regardant de plus prêts, c’était la fonctionnalité ToString qui m'intéressait.

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

Ce que certains développeurs apprécient car on peut vérifier simplement l'instanciation.

Et il ne s'agissait donc pas de GetHashCode, mais de ToString.
Mais j'ai tout de même utilisé MyBase comme tu l'as indiqué, et ça marche très bien :

Code:

---

1 2 3 4

<System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)> Public Overloads Function ToString() As String Return MyBase.ToString End Function

---

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...
Mais bon ça marche, je vais pas me plaindre.

Merci bien !

DonQuiche résume bien le problème. Cette méthode n'est pas là pour faire joli, elle a une vraie utilité, et il ne faut pas l'implémenter n'importe comment, sinon on casse tout...

Si tu veux vraiment la cacher (ce que je trouve plus que discutable), prends plutôt la solution de rv26t.

Citation:

---

Envoyé par mactwist69

En fait en y regardant de plus prêts, c’était la fonctionnalité ToString qui m'intéressait.

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

Ce que certains développeurs apprécient car on peut vérifier simplement l'instanciation.

---

Je ne vois pas le rapport entre ToString et le fait de vérifier si une variable est nulle :koi:

Citation:

---

Envoyé par mactwist69

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...

---

Si, elle dérive de Object, comme toutes les classes qui n'ont pas de classe de base explicite

Citation:

---

Envoyé par mactwist69

Salut rv26t,

En fait en y regardant de plus prêts, c’était la fonctionnalité ToString qui m'intéressait.

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

Ce que certains développeurs apprécient car on peut vérifier simplement l'instanciation.

---

Toi tu viens du php ou d'un langage de ce genre qui compare des chaînes à la structure de l'objet, non ?

En tout cas sache que nombre de développeurs C# considèreront ça comme un comportement exécrable, surprenant, qui va à l'encontre du langage et de ses conventions. Pour ma part je te conseille de travailler en C# avec les habitudes du C# et en php avec les habitudes du php.

Citation:

---

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...

---

Si, toute classe et tout type valeur dérive de Object.

Citation:

---

Envoyé par mactwist69

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...

---

Euh si ta classe dérive d'Object

Citation:

---

Envoyé par mactwist69

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

---

:koi: pas sûr d'avoir compris, pour tester la nullité d'une instance vous la comparez avec la chaine "Nothing" ; y'a mieux comme moyen

grillé par DonQuiche

Citation:

---

Envoyé par DonQuiche

Tu réalises qu'en modifiant ainsi le comportement de GetHashCode les dictionnaires et HashSet qui contiendraient ces objets rameraient comme ce n'est pas permis, ce qui sur un serveur serait une sacrée brèche pour une attaque DDOS ?

---

Et bien non, je ne réalisais pas.
C'est bien noté.

Citation:

---

Envoyé par tomlev

Je ne vois pas le rapport entre ToString et le fait de vérifier si une variable est nulle :koi:

---

Code:

---

If MonObjet IS Nothing Then

---

Lorsque l'objet est instancié, le test renvoi False.
Quand l'objet n'est pas instancié, il renvoi True.

Lorsque ToString a été écrasé (pour envoyer toujours nothing), ce test renvoi toujours True, Il est là le rapport.

Citation:

---

Envoyé par DonQuiche

Toi tu viens du php ou d'un langage de ce genre qui compare des chaînes à la structure de l'objet, non ?

En tout cas sache que nombre de développeurs C# considèreront ça comme un comportement exécrable, surprenant, qui va à l'encontre du langage et de ses conventions. Pour ma part je te conseille de travailler en C# avec les habitudes du C# et en php avec les habitudes du php.

---

Ben raté, je ne fais que du VB que j'essai de faire en VB.

Ce n'est pas moi qui ait mis en place ces tests de Nothing sur la structure de l'objet.
Mais je poserai la question à celui qui à mis ça en place.

Citation:

---

Envoyé par mactwist69

Code:

---

If MonObjet IS Nothing Then

---

Lorsque l'objet est instancié, le test renvoi False.
Quand l'objet n'est pas instancié, il renvoi True.

Lorsque ToString a été écrasé (pour envoyer toujours nothing), ce test renvoi toujours True, Il est là le rapport.

---

Euh... non, le fait de redéfinir ou de masquer ToString ne change rien à ce test. Je te mets au défi de me prouver le contraire ;)
Ca pourrait avoir un sens si tu faisais If MonObjet.ToString() Is Nothing, sauf que ça planterait quand MonObjet est Nothing

Citation:

---

Envoyé par tomlev

Euh... non, le fait de redéfinir ou de masquer ToString ne change rien à ce test. Je te mets au défi de me prouver le contraire ;)
Ca pourrait avoir un sens si tu faisais If MonObjet.ToString() Is Nothing, sauf que ça planterait quand MonObjet est Nothing

---

J'en dis des conneries hein ?
Faut que j'arrête de bosser le lundi.

Faut pas utiliser IsNothing (la fonction issue des vieux trucs de compatibilité VB6) ;)
http://i.imgur.com/Z9tUet7s.png?1

Edit: Note à moi-même ; ouvrir mieux les yeux le lundi aussi :aie: ; IsNothing renvoie les même résultats que Is Nothing (normal vu que son implémentation utilise Is Nothing :roll:)

Citation:

---

Envoyé par Sehnsucht

Faut pas utiliser IsNothing (la fonction issue des vieux trucs de compatibilité VB6) ;)
http://i.imgur.com/Z9tUet7s.png?1

---

Bon a savoir, je ne m'étais jamais posé la question, déjà parce que je ne savais pas que IsNothing vient de vb6...
Je suis pas assez vieux (ou expérimenté) il faut croire.

Salut,

Pas sûr que IsNothing existe en VB6 parce qu'il n'existe pas en VBA.
IsObject existe par contre, alors je pense que IsNothing et IsObject ont été interchangé entre VB6 et VB.NET vu que IsObject n'existe plus en VB.NET.

C'été juste en passant :).