Reprise du message précédent :
 
T'emballe pas, c'est quand-même nettement plus couteux que d'utiliser une chaine
Par rapport à la réflection, je sais pas trop, faudrait benchmarker...
Enfin de toutes façons, ça sert essentiellement pour les scénarios de binding, donc les perfs ne sont pas critiques en général
 
 
 
Ca ressemble à un marqueur UTF-8... vérifie l'encodage du fichier. Perso j'ai jamais eu ce problème
 
 
 
T'es sûr ? Ca me semble bizarre, vu que le moteur de template utilise le compilateur C# 3...

 
Je suis confiant, encore bravo et bonne continuation!
 

 
Oui c'est normal. Oui et non, je ne l'utilise pas tel quel, pour l'instant je me suis contenté d'y reprendre au coup par coup uniquement ce qui m'intéresse.
 

 
C'est vrai que c'est excellent comme truc, je ne comprend pas que ça n'ait pas été plus mis en avant ou fusionné avec les Code Snippets.

Tiens je connaissais pas ce machin !
Au dela du côté extensions, il doit y avoir pas mal de petits algos sympatoches à puiser...

edit : en fait il y a vraiment de tout, des méthodes super mal nommées, des trucs très bons... Et il y a même des sommités qui postent là bas apparemment, j'ai vu quelques noms connus, type Scott Guthrie...

Je profite de ce topic
 
 
Je suis amené à gerer une collection, qui est indexé à l'aide d'un autre objet (Attention les yeux):
 

 
J'ai l'impression que c'est crado, mais j'ai pas beaucoup d'idée pour faire plus propre (et simple). Bon en plus l'extension méthode "Contains" me servira pas puisque ma clé n'est pas un type primitif. (J'utilise du coup le Where<>, mais moins pratique )

Je ne comprend pas du tout pourquoi tu parles de méthode d'extension (un usage impropre du terme peut être?). Et contains fonctionne aussi sur les types références. J'ai un peu de mal à te suivre.

A part ça c'est pas choquant comme truc. En fonction des opérations que tu dois faire sur la liste dans le dico tu peux peut être remplacer le tout par un Lookup (un type générique introduit dans .Net 3, je te laisse trouver un tuto).
Là je m'exprime juste sur le dico qui embarque en value une List, faut voir ce que font SiteInfo et ResourceInfo pour proposer une alternative vraiment différente.

Je parlais de la méthode d'extension bool IEnumerable <Tsource>.Contains(... )  Définie dans System.linq. Je me plante de terme ? Bon bref passons    
 
 
 
Je regarde Lookup  

Ah ok. Non je pensais juste à la version "non linq" du Contains, qui vient de ICollection ou un truc du genre.
Je ne pensais pas à la version "méthode d'extension" (qui existe effectivement!) d'abord parce que je ne m'en sers pas ( ), et ensuite parce qu'hormis la possibilité de spécifier un ICOmparer particulier (dont tu te fous sans doute) elle n'a rien d'intéressant, je ne voyais pas trop pourquoi tu en parlais. Bref.

edit : enfin en fait il n'y a pas de Contains autre qu'en méthode d'extension sur les dico, c'est pour les listes évidemment, sorry

Pour un dico effectivement Contains ne sert quasi à rien (sauf si tu as déjà la keyvaluepair). Si tu veux passer une lambda pour ta sélection, tu utilises un where, sinon containskey.

 
Il faudrait déjà préciser ce que tu cherches à faire... En supposant que tu cherches à vérifier l'existence d'une clé spécifique, la méthode ContainsKey me semble assez adaptée. Par contre ça suppose d'avoir redéfini les méthodes Equals et GetHashCode dans la classe SiteValue, ou alors de passer un IEqualityComparer<SiteInfo> en paramètre du constructeur pour décider si 2 SiteInfo sont égaux.
 
Si ce n'est pas ça, précise ta question

L'instance que je vais chercher aura les même valeurs, mais ne sera pas la même que dans le dictionnaire malheureusement.
 
Je m'en suis sortit sans problème avec le Where, et effectivement je n'avais pas pensé au containsKey + Lambda.
 
Enfin je m'en sors sans trop de problème, mais je me demandai juste si c'etait pas trop degueux, de faire une dico, avec un objet comme clé, et des List Comme contenu, car je trouve que c'est ptet pas forcement lisible et il y avais peut etre plus "propre"

En fait disons en .net 1.1, dès qu'il y avait des collections avec un peu de spécifique à gérer, le mieux etait de developper soit même ses classes de collection et d'élément en héritant des classes de collections et élément de base fournit par le Framework.
 
Maintenant, avec les Generics, j'ai tendance à utiliser à toutes les sauces les dictionnaires et list , ou même faire des classes qui héritent de List<>.  

C'est tout à fait normal d'abuser des generics, ils sont là pour ça, depuis le temps qu'on les attendais avec .NET 1.1

C'est clair que ça + link, comment ça change la vie    
 

 
Bien joué, ils n'en auront pas un en plus  

 
ça fait 4 ans que je refuse de faire autre chose que du .NET (on m'a même demandé des services en Cobol récemment... plus JAMAIS de la vie !)

Bon sinon quand est ce que la sous cat .NET sera visible de la page principale  

j'avais jamais fait gaffe

Ouais, enfin s'il fait du .NET au même rythme qu'il s'occupe de son topic "Effets Demos OldSchool en asm"...  

Histoire que ça soit quand même quelque part avant que je le dégage, pour un option type C# vous préférez (même interface dans les deux cas) un type unique:

class Nullable<T>
    {
        readonly bool hasValue;
        readonly T value;
 
        public bool HasValue { get { return hasValue; } }
 
        public Nullable()
        {
            hasValue = false;
            value = default(T);
        }
        public Nullable(T value)
        {
            hasValue = true;
            this.value = value;
        }
 
 
        public T GetOrDefault()
        {
            return value;
        }
        public T GetOrDefault(T def)
        {
            if (!hasValue)
                return def;
            return value;
        }
        public Nullable<K> Map<K>(Func<T, K> mapper)
        {
            if (!hasValue)
                return new Nullable<K>();
            return new Nullable<K>(mapper(value));
        }
 
        public Nullable<T> Execute(Action<T> ifHasValue, Action ifHasNoValue)
        {
            if (hasValue)
                ifHasValue(value);
            else
                ifHasNoValue();
            return this;
        }
        public Nullable<T> Execute(Action<T> ifHasValue)
        {
            if (hasValue)
                ifHasValue(value);
            return this;
        }
        public Nullable<T> Execute(Action ifHasNoValue)
        {
            if (!hasValue)
                ifHasNoValue();
            return this;
        }
    }

 
ou une hiérarchie avec un ADT au sommet et deux implés concrètes  

public interface Nullable<T>
    {
        bool HasValue { get; }
        T GetOrDefault();
        T GetOrDefault(T def);
        Nullable<K> Map<K>(Func<T, K> map);
        void Execute(Action<T> ifHasValue, Action ifHasNoValue);
        void Execute(Action<T> ifHasValue);
        void Execute(Action ifHasNoValue);
    }
    public class Some<T> : Nullable<T>
    {
        private T value;
        public Some(T value)
        {
            this.value = value;
        }
 
        public bool HasValue { get { return true; } }
        public T GetOrDefault() { return value; }
        public T GetOrDefault(T def) { return value; }
        public Nullable<K> Map<K>(Func<T, K> map) { return new Some<K>(map(value)); }
        public void Execute(Action<T> ifHasValue, Action ifHasNoValue) { ifHasValue(value); }
        public void Execute(Action<T> ifHasValue) { ifHasValue(value); }
        public void Execute(Action ifHasNoValue) { }
    }
    public class Null<T> : Nullable<T>
    {
        public bool HasValue { get { return false; } }
        public T GetOrDefault() { return default(T); }
        public T GetOrDefault(T def) { return def; }
        public Nullable<K> Map<K>(Func<T, K> map) { return new Null<K>(); }
        public void Execute(Action<T> ifHasValue, Action ifHasNoValue) { ifHasNoValue(); }
        public void Execute(Action<T> ifHasValue) { }
        public void Execute(Action ifHasNoValue) { ifHasNoValue(); }
    }

?
 

 
edit: also faudrait probablement dégager GetOrDefault() et ajouter un Execute(Action, Action<T> ) pour avoir une meilleure interface maintenant que j'y pense, et au final dans le 2e cas HasValue n'a qu'un intérêt très limité dans la mesure où on peut juste tester le type concret.

http://en.wikipedia.org/wiki/Option_type

Nope, il est pourri et il est que pour les values, c'est pas un option type générique.

C'est une version type-safe de "null", et avec la bonne interface tu peux lifter des opérations dans ton conteneur ce qui te permet de ne pas te poser de questions sur "y a-t-il ou non une valeur dedans" parce que c'est le conteneur qui se démerde et dispatche correctement. System.Nullable fait du lifting sur les opérateurs pour que tu puisses écrire "a += 1" quand a est un Nullable<int> donc potentiellement null sans avoir à checker si c'est une valeur ou un null.

Sauf que dans ce cas, quand tu unwrap tu dois tester sur HasValue, alors qu'avec les types concrets tu testes sur le type (built-in, une property de moins) et les implés sont inconditionnelles (puisque la condition est résolue à la création des instances).

Et tu peux avoir des méthodes/properties spécifiques sur les types concrets, genre Get sur Some qui renverrait directement this.value, mais qui ne serait appellable qu'après avoir casté en Some et donc vérifié que c'était possible (sinon logiquement le compilo gueule)

C'est le genre de trucs qui peuvent paraitre un peu abstraits ou inutiles quand on n'a jamais fait de prog fonctionnelle . Après c'est clair qu'en C# ça ne sert pas tous les jours parce qu'il y a plein de moyens plus ou moins naturels de faire autrement...

Naturellement, F# est une réimp de OCaml.

Tiens, au passage, une petite lib utilisée depuis ce matin
 
AutoMapper (mapping objet-objet, utilisé de mon côté pour simplifier le sale boulot entre mes Models et ViewModels)

Pas mal. Evidemment on peut arriver au même résultat de plein de façons à la mimine mais ça peut être intéressant d'automatiser en s'appuyant sur un substrat commun plutôt que des classes adaptatrice et des constructeurs de recopie dans tous les cas,Surtout lorsque on a pas mal de mappings différents à faire.

edit : ajouté au deuxieme post pour info...

Tiens petite idée de débat : MVC ou Webforms ?
 
C'est peut être faute de m'y être suffisamment intéressé mais j'ai jamais été foutu de franchir le pas à MVC, même si je lis de plus en plus souvent que les webforms c'est has been, surtout en RAD.  
 
Pourtant je reste un adepte de cette techno, dont les qqes inconvénients qui fournissent des arguments à l'avantage du MVC peuvent être corrigés selon moi (archi ntiers pour l'aspect SOC et l'extensibilité, viewstate serveur, etc).
 
Vous bossez en quoi vous ? Pourquoi ?

Non, pas possible : en MVC le ViewState est désactivé, et la plupart des contrôles serveur WebForms dépendent du ViewState
Par contre MS vient de créer un nouveau moteur de vues appelé Razor, qui permet de simplifier l'écriture des vues HTML

Je pose mon drapeau.

Histoire de remettre 10 frs dans le nourrin, si je veux utiliser Entity Framework avec Oracle, c'est quoi le "mieux" aujourd'hui ? (pas en 2011 )