enum

DBType ?

sinon, pour répondre à l'autre partie de ta question :

sealed class Dummy
{
private Dummy()
{
}

public static readonly Dummy Valeur1 = new Dummy() ;
public static readonly Dummy Valeur2 = new Dummy() ;
}

l'Enum n'etant pas une fin en soi

Merci pour la reponse, pzr contre je ne comprends pas la phrase suivante :
"l'Enum n'etant pas une fin en soi"

Cela veut dire que les enu mne sont pas recommande dans ca cas ?

Guy

"Ambassadeur Kosh" a écrit :

sinon, pour répondre à l'autre partie de ta question :

sealed class Dummy
{
private Dummy()
{
}

public static readonly Dummy Valeur1 = new Dummy() ;
public static readonly Dummy Valeur2 = new Dummy() ;
}

l'Enum n'etant pas une fin en soi

> Cela veut dire que les enum ne sont pas recommande dans ca cas ?

les enum ne sont "en général" qu'une étape.
et ils ont quelques "defauts" qu'il semble bon d'eradiquer.

posons le decors : on a une appli web qui écrit du document pdf word ou
excel directement dans le response. ça ouvre l'appli concernée à l'interieur
d'IE avec le document. pour obtenir ce miracle, il faut faire ce genre de
chose

pour Excel : Response.ContentType="application/vnd.ms-excel" ;
pour Word, Response.ContentType="application/word" ;

donc c'est chiant. on passe direct à la trappe l'idée de faire des const
string, puisque du moment qu'une fonction attend une string, on peut lui
passer "dudule" et ça compile. idée : faire un Enum

enum ContentType { Pdf, Word, Excel }

une classe HttpResponseWriter, qui prend un ContentType en construction.
ensuite, un switch la dedans, et le tours et joué.

probleme : si dans l'avenir, on ajoute une valeur dans l'Enum, et qu'on
oublie le switch 20000 lignes plus bas, ça compile et ça dit rien.

probleme : les Enums peuvent se combiner entre eux à coup d'operateurs
binaires, et se caster en valeurs de 'representation', en general, int. une
vraie foutaise, qui permet de passer en toute légalité à la fonction des
valeurs qui n'ont pas de sens.

idée (pompée sur les encoding)

sealed class ContentType
{
private ContentType(string content) { this.content = content ; }

private string content ;

public string Content { get { return content ; }}

public static readonly ContentType Pdf = new
ContentType("application/pdf") ;
public static readonly ContentType Excel = new
ContentType("application/vnd.ms-excel") ;
public static readonly ContentType Word = new
ContentType("application/word") ;
}

et voila. ça a la sémantique d'un vrai enum, sans les defauts, et c'est
correct et complet : pas de vide.

dans le cheminement d'un code, c'est souvent comme ça : on commence à
raisonner constante, apres, on pense enum, apres, ça devient des classes.

et pour boucler la boucle, j'espere que tu ne vas pas reinventer la roue.

ah oui, un dernier truc. l'outils Reflector décompile le code de n'importe
quel assembly en C# en VB (ce que tu veux ). tu peux ainsi rapidement
trouver comment sont obtenus certains mécanismes comme celui que nous venons
d'evoquer, en t'inspirant des classes existantes.

voila voila

un autre problème avec les enum est que si un jour une
nouvelle valeur doit être ajoutée, on ne peut pas le
faire sans casser la compatibilité.

C'est a vrai dire surtout un pbl pour les éditeurs de
logiciel qui distribuent de par le monde leurs composants.
Pour une appli lambda, le problème est surtout celui
souligné par Kosk

-----Original Message-----

Cela veut dire que les enum ne sont pas recommande

dans ca cas ?

les enum ne sont "en général" qu'une étape.
et ils ont quelques "defauts" qu'il semble bon

d'eradiquer.

posons le decors : on a une appli web qui écrit du

document pdf word ou

excel directement dans le response. ça ouvre l'appli

concernée à l'interieur

d'IE avec le document. pour obtenir ce miracle, il faut

faire ce genre de

chose

pour Excel : Response.ContentType="application/vnd.ms-

excel" ;

pour Word, Response.ContentType="application/word" ;

donc c'est chiant. on passe direct à la trappe l'idée de

faire des const

string, puisque du moment qu'une fonction attend une

string, on peut lui

passer "dudule" et ça compile. idée : faire un Enum

enum ContentType { Pdf, Word, Excel }

une classe HttpResponseWriter, qui prend un ContentType

en construction.

ensuite, un switch la dedans, et le tours et joué.

probleme : si dans l'avenir, on ajoute une valeur dans

l'Enum, et qu'on

oublie le switch 20000 lignes plus bas, ça compile et ça

dit rien.

probleme : les Enums peuvent se combiner entre eux à

coup d'operateurs

binaires, et se caster en valeurs de 'representation',

en general, int. une

vraie foutaise, qui permet de passer en toute légalité à

la fonction des

valeurs qui n'ont pas de sens.

idée (pompée sur les encoding)

sealed class ContentType
{
private ContentType(string content) { this.content =

content ; }

private string content ;

public string Content { get { return content ; }}

public static readonly ContentType Pdf = new
ContentType("application/pdf") ;
public static readonly ContentType Excel = new
ContentType("application/vnd.ms-excel") ;
public static readonly ContentType Word = new
ContentType("application/word") ;
}

et voila. ça a la sémantique d'un vrai enum, sans les

defauts, et c'est

correct et complet : pas de vide.

dans le cheminement d'un code, c'est souvent comme ça :

on commence à

raisonner constante, apres, on pense enum, apres, ça

devient des classes.

et pour boucler la boucle, j'espere que tu ne vas pas

reinventer la roue.

.