> Pensez-vous que de déclarer une propriété privée au sein d'une structure qui y fait appel pour une méthode statique présente un risque ?
tu peux la refaire la ? je dirais bien "vas y", mais je voudrais être certain d'avoir vu le truc.
sinon, question habituelle, pourquoi pas plutot une class ?
Bismark Prods
Hello,
"Ambassadeur Kosh" a écrit dans le message de news:uxIXM%
> Pensez-vous que de déclarer une propriété privée au sein d'une structure > qui > y fait appel pour une méthode statique présente un risque ?
tu peux la refaire la ? je dirais bien "vas y", mais je voudrais être certain d'avoir vu le truc.
sinon, question habituelle, pourquoi pas plutot une class ?
Je commence par la fin ... une structure car il s'agit d'un type primitif. Imaginons que je veuille (c'est pas vrai) créé un type entier qui aurait la particularité d'etre un entier pair. Je crée donc mon type structure et des constructeurs, des surcharges d'opérateurs etc etc...
Il y a forcément un moment dans toutes ces surcharges, ou je dois dire d'ou provient la propriété par défaut. Tel que public static implicit operator long(MyStruct type) et là je dois retourner la variable privée interne à la structure. Mais je veux pas que cette variable et a travers elle la propriété qui y correspond soit public. Je veux que pour l'utilisateur de ma structure les choses soit le plus simple possible.
MyStruct x = 10;
et pas
MyStruct x = new MyStruct(10);
et apres
long y = x + 10; etc...
Suis-je plus clair ?
Bonne soirée
Hello,
"Ambassadeur Kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
news:uxIXM%23nnEHA.3988@tk2msftngp13.phx.gbl...
> Pensez-vous que de déclarer une propriété privée au sein d'une structure
> qui
> y fait appel pour une méthode statique présente un risque ?
tu peux la refaire la ? je dirais bien "vas y", mais je voudrais être
certain d'avoir vu le truc.
sinon, question habituelle, pourquoi pas plutot une class ?
Je commence par la fin ... une structure car il s'agit d'un type primitif.
Imaginons que je veuille (c'est pas vrai) créé un type entier qui aurait la
particularité d'etre un entier pair.
Je crée donc mon type structure et des constructeurs, des surcharges
d'opérateurs etc etc...
Il y a forcément un moment dans toutes ces surcharges, ou je dois dire d'ou
provient la propriété par défaut. Tel que public static implicit operator
long(MyStruct type) et là je dois retourner la variable privée interne à la
structure. Mais je veux pas que cette variable et a travers elle la
propriété qui y correspond soit public. Je veux que pour l'utilisateur de ma
structure les choses soit le plus simple possible.
"Ambassadeur Kosh" a écrit dans le message de news:uxIXM%
> Pensez-vous que de déclarer une propriété privée au sein d'une structure > qui > y fait appel pour une méthode statique présente un risque ?
tu peux la refaire la ? je dirais bien "vas y", mais je voudrais être certain d'avoir vu le truc.
sinon, question habituelle, pourquoi pas plutot une class ?
Je commence par la fin ... une structure car il s'agit d'un type primitif. Imaginons que je veuille (c'est pas vrai) créé un type entier qui aurait la particularité d'etre un entier pair. Je crée donc mon type structure et des constructeurs, des surcharges d'opérateurs etc etc...
Il y a forcément un moment dans toutes ces surcharges, ou je dois dire d'ou provient la propriété par défaut. Tel que public static implicit operator long(MyStruct type) et là je dois retourner la variable privée interne à la structure. Mais je veux pas que cette variable et a travers elle la propriété qui y correspond soit public. Je veux que pour l'utilisateur de ma structure les choses soit le plus simple possible.
MyStruct x = 10;
et pas
MyStruct x = new MyStruct(10);
et apres
long y = x + 10; etc...
Suis-je plus clair ?
Bonne soirée
Ambassadeur Kosh
> Je veux que pour l'utilisateur de ma structure les choses soit le plus simple possible.
ben autant s'inspirer de celles qui existent alors. genre le DateTime ou une autre
Suis-je plus clair ?
pige toujours pas l'interet de le rendre implicite. faut le rendre explicite. regardes en C#, tu n'affectes pas de float à un double ou de double à un float sans faire explicitement le cast. cast implicite = source d'embrouilles. ça va masquer des erreurs d'innatention, et affaiblir le typage. j'en ai fait les frais en C++, ça conduit à des erreurs que tu mets des plombes à trouver ( notament avec la stl ) et que tu ne vois pas à la compilation, mais plutot chez le client en démo :o(
struct NombrePrecisionInfinie { struct NombrePrecisionInfinie(double x) ; public static Complex operator + (NombrePrecisionInfinie x,NombrePrecisionInfinie y) ; public static Complex operator + (NombrePrecisionInfinie x,int y) ; public double ToDouble() ; }
pas un cast. c'est pas beau ça ?
NombrePrecisionInfinie x = new NombrePrecisionInfinie(10) ; NombrePrecisionInfinie y = x + 5 ; double result = y.ToDouble() ;
et pour la nunuche qui veux pas se tuer le cerveaux ou se salir les doigts à ecrire ToDouble(), tu lui fouts une trempe et puis c'est tout... :o)
-- Ambassadeur Kosh Vorlon qui comprend G'Kar.
> Je veux que pour l'utilisateur de ma
structure les choses soit le plus simple possible.
ben autant s'inspirer de celles qui existent alors.
genre le DateTime ou une autre
Suis-je plus clair ?
pige toujours pas l'interet de le rendre implicite. faut le rendre
explicite.
regardes en C#, tu n'affectes pas de float à un double ou de double à un
float sans faire explicitement le cast.
cast implicite = source d'embrouilles. ça va masquer des erreurs
d'innatention, et affaiblir le typage. j'en ai fait les frais en C++, ça
conduit à des erreurs que tu mets des plombes à trouver ( notament avec la
stl ) et que tu ne vois pas à la compilation, mais plutot chez le client en
démo :o(
struct NombrePrecisionInfinie
{
struct NombrePrecisionInfinie(double x) ;
public static Complex operator + (NombrePrecisionInfinie
x,NombrePrecisionInfinie y) ;
public static Complex operator + (NombrePrecisionInfinie x,int y) ;
public double ToDouble() ;
}
pas un cast. c'est pas beau ça ?
NombrePrecisionInfinie x = new NombrePrecisionInfinie(10) ;
NombrePrecisionInfinie y = x + 5 ;
double result = y.ToDouble() ;
et pour la nunuche qui veux pas se tuer le cerveaux ou se salir les doigts à
ecrire ToDouble(), tu lui fouts une trempe et puis c'est tout... :o)
> Je veux que pour l'utilisateur de ma structure les choses soit le plus simple possible.
ben autant s'inspirer de celles qui existent alors. genre le DateTime ou une autre
Suis-je plus clair ?
pige toujours pas l'interet de le rendre implicite. faut le rendre explicite. regardes en C#, tu n'affectes pas de float à un double ou de double à un float sans faire explicitement le cast. cast implicite = source d'embrouilles. ça va masquer des erreurs d'innatention, et affaiblir le typage. j'en ai fait les frais en C++, ça conduit à des erreurs que tu mets des plombes à trouver ( notament avec la stl ) et que tu ne vois pas à la compilation, mais plutot chez le client en démo :o(
struct NombrePrecisionInfinie { struct NombrePrecisionInfinie(double x) ; public static Complex operator + (NombrePrecisionInfinie x,NombrePrecisionInfinie y) ; public static Complex operator + (NombrePrecisionInfinie x,int y) ; public double ToDouble() ; }
pas un cast. c'est pas beau ça ?
NombrePrecisionInfinie x = new NombrePrecisionInfinie(10) ; NombrePrecisionInfinie y = x + 5 ; double result = y.ToDouble() ;
et pour la nunuche qui veux pas se tuer le cerveaux ou se salir les doigts à ecrire ToDouble(), tu lui fouts une trempe et puis c'est tout... :o)