J'ai envisagé 2 cas:
var a = new { a = 5, b = 7 }; var b = new { b = 7, a = 6 }; Console.WriteLine(a.GetType() == b.GetType()); // False
3 Réponses :
C # Spécification de la langue, section 7.6.10.6, nécessite que la séquence de propriétés soit la même pour que les types anonymes soient considérés comme identiques: p>
Dans le même programme, deux initialisateurs d'objets anonymes qui spécifient une séquence de propriétés des mêmes noms et des types de temps de compilation dans le même ordre produiront des instances du même type anonyme. P> blockQuote>
Dans votre deuxième exemple, la première classe anonyme a la séquence de propriétés
{A, B} code>, tandis que la deuxième classe anonyme a la séquence
{b, a} code> . Ces séquences ne sont pas considérées comme les mêmes. P>
Merci, bien que votre réponse n'a rien à voir avec ma question.
Eh bien, cette réponse soulève simplement la question de savoir pourquoi la spécification est écrite de cette façon. Eric Lippert répond ici .
@ARTUR UDOD: Je n'irais pas aussi loin.
@Jason, oui, merci et odé pour cet article. Aurait accepté si c'était un asnwer.
@ARTURUDDOD Je suis confus quant à la manière dont cela ne concerne pas votre question. Vous avez demandé pourquoi la commande compte, répondit-il. J'ai lu votre question et j'ai lu sa réponse, tout cela a eu sens pour moi.
@Jeremyk c'est correct, mais "la spécification dit" n'est généralement pas une explication très satisfaisante.
Donc, C # fonctionne de cette façon, car cela est écrit dans la spécification C #? D'accord, allons pas plus loin: pourquoi C # Spec a écrit de cette façon.
@Rawling True, mais dire que cela n'avait rien à voir avec sa question n'est pas une déclaration précise :) il était un peu grossier imo.
@ARTURUDDOD "La question est de savoir pourquoi l'ordre des champs est-il réellement important? Y a-t-il une raison pour cela ou c'est tout simplement parce que c'est (tel est le design)". Votre question était assez générique pour une réponse générique. Vous vouliez savoir si c'était comme ça parce qu'il a été conçu de cette façon. Sa réponse droite a dit oui, c'est ainsi que la langue a été conçue.
@Jeremyk, si j'étais, je m'excuse, ce n'était pas intentionnellement. Je ne suis pas une langue anglaise autochtone, alors mes phrases sont brutes et simples.
Assez juste :) Je comprends le désir de plus d'informations. Je pensais juste qu'il avait fourni la réponse à ce qui a été demandé. /Acclamations
@ARTURUDDOD "... n'a rien à voir avec ma question." Pourquoi? Vous n'avez pas demandé "pourquoi l'ordre des champs est-il réellement important?" La réponse est "parce que la spécification le dit". Si vous vouliez savoir pourquoi la spécification a été écrite de cette façon, vous auriez dû demander cela explicitement. (Ensuite, je ne répondrais probablement pas, car toutes les questions sur "Pourquoi la spécification a été écrite ceci ou de cette façon" sont abordées principalement à Eric Lippert :-)
@Jeremyk, je vous demandais s'il y a une raison spécifique à cela, et il y a en fait: les implémentations de gethashcode & Tostring ().
car la spécification dit que code> est une réponse authentique à toutes les questions commençant par
pourquoi compiler ... code>
@ARTURUDDOD n'est pas universellement vrai: parfois, la spécification donne des compilateurs une certaine liberté de ce qu'ils peuvent faire; Parfois, la spécification ne dit rien d'un problème particulier; Parfois, les compilateurs ont des bugs. Quoi qu'il en soit, si vous vouliez discuter des raisons de la spécification écrite d'une manière ou d'une autre, vous auriez dû poser des questions sur les spécifications, pas sur un comportement de programme.
@dasblinkenlight, d'accord, j'ai eu votre point. Désolé si j'étais offensant. Merci pour votre réponse, et BTW, je vous ai donné un upvote, je voulais juste aller un peu plus profondément.
Vous conduisez à ce que je devine la raison est: les types sont anonymes, donc en fonction de Tant pourquoi le compilateur réutilise un type si la commande correspond, je suppose que c'est simplement pour gagner du temps et de l'espace. Lorsque vous prenez en compte la commande, il est beaucoup plus facile de mettre en cache des classes générées pendant la compilation, puis de les réutiliser en cas de besoin. P> gettype () code> pour retourner des résultats fiables est une idée terrible. P>
Cela a également à voir avec eux ayant des représentations de totrage appropriées.
Donc, la raison de la décision de conception était démo p> p> Tostring code>. Un type anonyme renvoie une chaîne code> différente code> à la commande. Lire Blog d'Eric Lippert .
Je suppose que la mise en œuvre gethashcode code> dépend également de la commande.
@Rawling: Oui, ça fait. Cependant, les deux dépendent les uns des autres. Donc différent tostring code> avec le même hashcode ou le même hashcode sur différents
Tostring code> aurait été un piège.
@ Timschmelter: Pourquoi le même hashcode mais différent Tostring code> a été un piège? Avoir
est égal à Code> Méthodes Signaler des instances de différents types, car un piège serait un piège, mais des collisions de code de hachage occasionnelles entre des objets inégaux sont raisonnablement attendues.
Quels moyens "les types d'anonymus ne sont pas censés être utilisés de cette façon" i>? Quel voie? Qu'essayez-vous de faire?
Eric Lippert a blogué à propos de cette chose exacte: blogs.msdn.com/b/ericlippert/archive/2012/01/30/...
Une raison légèrement banale est que la méthode
Tostring () code> pour les classes anonymes honore la commande dans laquelle les propriétés sont déclarées, de manière évidente des classes distinctes sont nécessaires pour prendre cela en compte.
Kinda-liée: Stackoverflow.com/Questtions/16794275/...
Est-ce un problème de programmation i> réel i>?
@ user414076, les problèmes peuvent être résolus pro-activement, non seulement de manière réactive. Je suis juste intéressé pourquoi le compilateur fonctionne-t-il de cette façon. Vous trouverez beaucoup de questions quelque peu similaires à ce sujet.