Discussion :

[ZaaN]

hello,

J'ai besoin de passer une collection à une fonction (en l'occurence un HashSet), qui doit lire dedant et dans certain cas agrandir la collection.

Mais j aimerais mettre en place un système qui empeche l'effacement ou le retraint d'un meembre de la collection.
des idées ?

[ced600]

Heu ... C'est toi qui code le HashSet ? Parce que dans un tel cas il te suffirait de ne pas faire d'ajout ou de retrait !!!

Après si ce n'est pas toi et que la fonction en fait tu as deux cas :

Soit tu veux conserver ta collection dans l'état où elle est et tu utilises le hashset pour avoir des info, dans ce cas, tu peux cloner ta collection, et passer le clone à la méthode.

Soit tu as absolument besoin de passer ta collection originale et la méthode provoque des modifs que tu ne veux pas avoir, bah dans ce cas là, tu es embêté.
Je ne sais pas s'il est possible de désactivé l'ajout, la modif, et le retrait temporairement, mais si c'est possible, il est probable que le HashSet génére une exception en tentant de le modifier.
Après une solution, est de faire un clone de la collection, de passer l'originale à la méthode, et après de vérifier les mdifs sur l'original en la comparant au clone, et de faire les modifications inverse.

[Bluedeep]

Bonjour

h
Mais j aimerais mettre en place un système qui empeche l'effacement ou le retraint d'un meembre de la collection.
des idées ?

cf. l'objet ReadOnlyCollection<T>.

Très pratique quand on veut retourner une collection à une classe cliente et qu'on veut s'assurer de l'impossibilité de modifier la collection sous jacente.

[ced600]

Connaissais pas.
Pas d'exception levée lorsque la méthode tente de modifier la collection ?

[Bluedeep]

Connaissais pas.
Pas d'exception levée lorsque la méthode tente de modifier la collection ?

Ben, non, car pas de méthodes de modification

C'est très pratique pour les propriétés publiques; tu peux l'utiliser ainsi par exemple :

Code :

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
 
class Portnawak
{
   private List<string> _myNames = new List<string>();
 
   // .... chargement de la list qq part dans la classe
 
   // Propriété publique en lecture seulement
   public ReadOnlyCollection<string> MyNames
   {
        get
        {
             return _myNames.AsReadOnly();
        }
   }
}

[ced600]

Ha c'est une méthode de Object ?
C'est comme cela qu'il gere cela.

[Bluedeep]

Ha c'est une méthode de Object ?

Gnnnn

kikidi ?

C'est comme cela qu'il gere cela.

J'ai pas trop suivi là.
Je montrais ce que je pense être la façon correcte d'exposer les collections dans des propriétés publiques, mais là je ne comprends pas bien de quoi tu me parles ?

[Guulh]

Ce n'est pas une méthode de object, mais de List. A noter quand même que la ReadonlyCollection<T> est une IList<T>, et donc une ICollection<T>, et donc qu'un instance de ReadOnlyCollection<T> doit forcément avoir une fonction Add, qui est cachée par le framework (implémentation explicite, peut être ?), mais est accessible si on force le cast en ICollection<T>. Ca doit balancer une exception, par contre.
C'est un sujet infini, ça, l'immuabilité des conteneurs ou la simulation de cette immuabilité

[Bluedeep]

Ok, je n'avais pas bien compris ce que voulait dire Ced600; tu as été plus imaginatif que moi

si on force le cast en ICollection<T>. Ca doit balancer une exception, par contre.

Eh oui : NotSupportedException

Code :

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

1
2
3
4
5
 
            List<string> list = new List<string>();
            list.Add( "cadena_uno" );
            ReadOnlyCollection<string> roc = list.AsReadOnly();
            (roc as ICollection<string>).Add( "cadena_dos" ); // raise an NotSupportedException

[ced600]

Ha ce n'est pas générique alors à tous les objets.
Je n'ai pas été très clair en effet, mais je pensais que l'auteur n'a pas forcement utilisé une liste générique, mais une autre collection, et qu'il ne peut pas forcement modifié le type qu'il utilise.
Donc c'est pas sur que la méthode est accessible pour lui.

[Bluedeep]

Ha ce n'est pas générique alors à tous les objets.

Non, mais c'est pour les listes génériques

Je n'ai pas été très clair en effet, mais je pensais que l'auteur n'a pas forcement utilisé une liste générique, mais une autre collection, et qu'il ne peut pas forcement modifié le type qu'il utilise.

Effectivement, ton objection s'éclaire là !
Mais ça peut être le moment justement pour éliminer ces listes non typées (pas boooooooooooo ......) et les remplacer par des génériques. (sauf si il est encore en 1.1, évidemment).

Ceci dit il parle de Hashset, qui, AFAIK, n'existe ni en 1.1 ni en 2.0 ou plus et sont plutôt java, donc .... je ne sais pas ce qu'il utilise.

EDIT : HashSet existe bien en 3.5, j'ignorais !!! (mais c'est bien une collection typée en revanche).

[ced600]

Dès le 1.1 tu peux faire des hastable.
Si je me souviens bien c'est dans les collections spécialisés (System.Collection.Specialized)

[Bluedeep]

Dès le 1.1 tu peux faire des hastable.
Si je me souviens bien c'est dans les collections spécialisés (System.Collection.Specialized)

Oui, mais les Hashtable ne sont pas génériques (concept inexistant en 1.1), les HashSet, oui.

[ced600]

Hum ok, il n'utilisais pas un terme générique avec HashSet pour désigner les table de hachage, mais un terme spécifique renvoyant à une classe de la version 3.5 du framework.

Hastable en tout cas n'est pas dans System.Colelction.Specialized, mais dans System.Collection

[Bluedeep]

Hum ok, il n'utilisais pas un terme générique avec HashSet pour désigner les table de hachage, mais un terme spécifique renvoyant à une classe de la version 3.5 du framework.

Oui, et comme toi, je ne m'en suis rendu compte qu'après coup (d'où mon EDIT).

Hastable en tout cas n'est pas dans System.Colelction.Specialized, mais dans System.Collection

Très certainement, mais, de toute façon, depuis le 2.0,je considère les Hahstable comme faisant parti du NS System.Oldies.Nanar

[Guulh]

Je me demande d'ailleurs si avec les dernières versions du framework, certaines classes / méthodes remplacées par des équivalents génériques ont commencé à être flaguées [Obsolete]. Entre le fx 2.0 et le 1.1, quasiment rien ne l'a été, mais ça serait pas mal que les petits jeunots qui attaquent directement le fx 3 ou 3.5 ignorent superbement les ArrayList et compagnie plutôt que d'hésiter et de faire des calculs de perf ou des suppositions hasardeuses J'ai quitté sans trop de regret le C++ pour le C# en partie parce qu'il n'avait pas trop d'éléments dans sa syntaxe ni dans sa lib standard qui soient un héritage d'un lourd passé (vive la dualité struct class qui sert à rien en C++ à part perturber mes collègues... )

[ZaaN]

barf...

j'uitilise bien le HashSet<T> générique supporté depuis .Net 3.5.

et je retiendrais la solution du clonage... avec verif par la suite. Comme je travaille avec un hashset ca devrait pas etre trop penalisant

[ced600]

Je me demande d'ailleurs si avec les dernières versions du framework, certaines classes / méthodes remplacées par des équivalents génériques ont commencé à être flaguées [Obsolete]. Entre le fx 2.0 et le 1.1, quasiment rien ne l'a été, mais ça serait pas mal que les petits jeunots qui attaquent directement le fx 3 ou 3.5 ignorent superbement les ArrayList et compagnie plutôt que d'hésiter et de faire des calculs de perf ou des suppositions hasardeuses J'ai quitté sans trop de regret le C++ pour le C# en partie parce qu'il n'avait pas trop d'éléments dans sa syntaxe ni dans sa lib standard qui soient un héritage d'un lourd passé (vive la dualité struct class qui sert à rien en C++ à part perturber mes collègues... )

Mais aussi dans ce cas il faut être sur de ne pas retomber dans le c++.
Or on en a pour au moins 50 ans encore.
J'admets que je pense que dans les 20 dernières années, ce sera un peu comme le cobol aujoud'hui