Non en lecture seule alternative pour les types anonymes

En C#, un type anonyme peut être comme suit:

method doStuff(){
     var myVar = new {
         a = false, 
         b = true
     }

     if (myVar.a) 
     {
         //Do stuff             
     }
}

Cependant, le suivant ne compile pas:

method doStuff(){
     var myVar = new {
         a = false, 
         b = true
     }

     if (myVar.a) 
     {
         myVar.b = true;
     }
}

C'est parce que myVar les champs sont en lecture seule et ne peuvent être cédés. Il semble vouloir faire quelque chose comme ce dernier est assez commun; peut-être la meilleure solution que j'ai vu est de définir une structure en dehors de la méthode.

Cependant, est-il vraiment pas d'autre façon de faire le bloc ci-dessus travail? La raison pour laquelle il me dérange, c'est, myVar est une variable locale de ce domaine, de sorte qu'il semble qu'il ne devrait être appelé à l'intérieur de la méthode qui l'utilise. En outre, besoin de place la structure en dehors de la méthode peut faire la déclaration d'un objet très éloigné de son utilisation, en particulier dans une longue méthode.

Mettre une autre manière, est-il une solution de rechange pour les types anonymes qui va me permettre de définir un "struct" comme ceci (je me rends compte struct existe en C#, et doit être définie en dehors d'une méthode) sans en faire lecture seule? Si non, est-il quelque chose de fondamentalement mauvais vouloir pour ce faire, et que je devrais être en utilisant une approche différente?

  • Les types anonymes sont conçus, pour une fois seulement, une utilisation rapide. Si votre utilisation est plus compliqué que cela, il y a tous les readsons pour créer un type nommé.
InformationsquelleAutor Superbest | 2012-01-28
  1. 31

    Pas, vous devrez créer votre propre classe ou structure pour ce faire (de préférence une classe, si vous voulez qu'il soit mutable - mutable structures sont horribles).

    Si vous n'avez pas de soins sur Equals/ToString/GetHashCode implémentations, c'est assez facile:

    public class MyClass {
    public bool Foo { get; set; }
    public bool Bar { get; set; }
}

    (J'aurais quand même utiliser les propriétés plutôt que de champs, pour diverses raisons.)

    Personnellement j'ai l'habitude de me surprends à vouloir un immuable type qui je peux passer entre des méthodes, etc - je veux un nom de version de l'existant anonyme de type de fonctionnalité...

    • Ce que je me surprends à vouloir un rapide raccourci pour la déclaration d'une structure avec des domaines particuliers, et une auto-généré constructeur qui prend des domaines tels que les paramètres. Remarque, d'ailleurs, que si une structure ne dispose pas de toutes les fonctions de membre qui modifient this ou des propriétés que l'accès à l'extérieur entités, un "immuable" struct et un "mutable" on va être impossible à distinguer de n'importe quel code qui n'est pas directement de tenter de modifier ses champs. Je peux voir des arguments à l'encontre de la tentative de modifier struct champs si on ne sait pas ce que l'on fait, mais ce n'est pas un argument pour avoir des structures en interdire telle modification.
    • J'en ai assez vu les problèmes causés par les structures mutables à éviter à tous, mais les plus spécialisés de situations. De telles situations certainement n'existe pas, mais je les trouve rare. Je pense que nous allons être d'accord d'être en désaccord sur l'opportunité mutable structures sont une bonne idée, compte tenu de votre réponse.
    • Combien de ces problèmes, ne comportent pas d'un struct méthode qui a écrit this? Pouvez-vous m'indiquer la description de tout (non-ce-écrit) les problèmes que vous avez vu qui ne sont pas clairement les résultats de quelqu'un qui n'a pas de comprendre comment les structures de travail (par exemple, quelque chose de saisissant à partir d'une collection, la modification de cette chose, et allègrement s'attendait à une mise à jour de la collection--quelque chose qui peut ou ne peut pas travailler avec des classes, et ne sera certainement pas travailler avec des structures)?
    • alors que vous savez peut-être tous les pièges possibles de mutables les structures, pouvez-vous garantir que chaque développeur qui maintient ou (si le public) consomme votre code sera au courant de ces? Alors que je ne suis pas un croyant dans le codage, pour le plus petit dénominateur commun, les structures mutables sont à l'opposé de mes préféré "fosse de la réussite."
    • Il suffit de garder un œil sur eux, sur un Débordement de Pile. Ce n'est pas seulement quand les choses compiler et puis ne fonctionnent pas comme prévu - c'est quand les gens attendre pour être en mesure de modifier des choses dans des situations où il ne serait vraiment pas les aider...
    • Aucun programmeur compétent doit s'attendre à ce que thing=Collection[index]; thing.someProperty=whatever; va modifier en toute sécurité Collection[index].someProperty; à moins qu'il ait examiné assez de code pour s'assurer que c'est le cas. Pourquoi devrait-on s'attendre à ce que d'un programmeur qui ne comprennent pas les structures seraient compétents pour reconnaître si oui ou non le code ci-dessus serait un moyen sûr de mettre à jour une propriété de classe-instance de type? Comme pour les personnes ayant "mutable struct mal" sur stack overflow, ils semblent tous se divisent en trois catégories: this mutations qui ne fonctionnent pas, ...
    • ...code qui tente de muter struct champs mais ne compile pas, ou du code qui utilise le comportement qui est inefficace, avec des structures et dangereux avec des classes. Je voudrais suggérer que le premier problème serait résolu en recommandant de "Ne pas modifier this sans une bonne raison."; le deuxième problème n'est pas fait pire avec les structures mutables que immuables; la le troisième problème est beaucoup moins de mal avec les structures mutables qu'avec mutable classes.
    • Comme je l'ai dit, je ne m'attends pas, nous allons finir par être d'accord. Je vais ajouter une catégorie bien: les structures qui sont mutables et de mettre en œuvre une mutation de l'interface, conduisant à des comportements différents lorsqu'ils sont en boîte à partir de quand ils ne sont pas en boîte...
    • Ceux qui tombent dans la catégorie des structures avec des méthodes qui permettent de modifier this; nous sommes d'accord que ceux qui sont problématiques. Notre seul point de désaccord, c'est que je pense que les structures devraient, dans de nombreux cas, exposer des champs publics, puisque l'on est autorisé à écrire des champs publics, dans les seuls cas où l'on serait autorisé à dire structVar = structVar.withField(whatever);, et avec essentiellement la même sémantique, sauf que le champ d'écriture sera plus rapide, de différents domaines peuvent être écrits dans différents threads sans interférence, et même-champ écrit peut être résolu par Interlocked.

    InformationsquelleAutor Jon Skeet
  2. 24

    Est-il une solution de rechange pour les types anonymes qui va me permettre de définir de manière concise un simple "enregistrer" type comme ça, sans prise en lecture seule?

    Pas. Vous aurez à faire un type nominal.

    Si non, est-il quelque chose de fondamentalement mauvais vouloir faire cela?

    Non, c'est raisonnable fonctionnalité que nous avons pris en considération avant.

    Je note que dans Visual Basic, les types anonymes sont mutable si vous le souhaitez.

    La seule chose qui est vraiment "fondamentalement mauvais" sur une mutable type anonyme, qu'il serait dangereux pour l'utiliser comme une clé de hachage. Nous avons conçu les types anonymes avec les hypothèses que (1) vous allez utiliser les touches dans equijoins dans une requête LINQ de compréhensions, et (2) dans LINQ-to-Objets et d'autres implémentations, les jointures seront mises en œuvre à l'aide de tables de hachage. Par conséquent, les types anonymes devraient être utiles en tant que clés de hachage, et mutable clés de hachage sont dangereux.

    Dans Visual Basic, le GetHashCode mise en œuvre ne consomme aucune information de champs mutables des types anonymes. Si c'est un compromis raisonnable, nous avons simplement décidé qu'en C# le supplément de complexité n'en valent pas la peine.

    • Je n'avais pas réalisé vb.net mise en œuvre des types anonymes à l'aide de classes avec les propriétés mutables. Cela semble être le pire choix possible. Il perd tous les avantages de performance l'on pourrait obtenir à partir d'un champ exposé (en lecture seule ou non), tous de la sémantique des avantages que l'on pourrait obtenir à partir d'une mutable struct (protégée contre la mutation par du code qui ne serait pas d'un accès suffisant pour remplacer l'occurrence avec un nouveau) ou immuable type.
    • ils sont éventuellement mutable en VB. Si vous n'aimez pas la fonctionnalité, vous n'avez pas à l'utiliser.
    • Ah, je vois. Les propriétés déclarées comme "clé" ne sont pas mutables-seulement ceux qui ne le sont pas. Je ne suis toujours pas sûr de ce qui a été obtenu en utilisant les propriétés mutables au lieu de champs pour le reste. Un membre doit être une propriété au lieu d'un champ si une classe ou (peut-être futur) dérivés pourrait vouloir non-comportement par défaut, mais depuis anonyme des classes mutable membres de toujours utiliser les comportements par défaut je ne suis pas clair ce qui est gagné par leur propriétés.
    • Une raison valable pour le faire propriétés est que les propriétés peuvent être liés à WPF. Ainsi, en utilisant les propriétés rend anonymes les classes utiles en tant que source de données pour WPF. Bien que cela puisse ne pas être la raison de la langue concepteurs/impelenters pris la décision, il ne l'appui de cette décision.
    • Je n'ai pas utilisé WPF; c'est l'idée qu'il utilise la Réflexion pour essayer de récupérer les propriétés à partir d'une instance de classe? Quelles sont les attentes de WPF à l'égard de la mutabilité? Les types anonymes n'ont pas l'infrastructure nécessaire pour assurer la sécurité de la mutation dans le contexte de l'accès asynchrone.
    • Il utilise la réflexion. Quant à muatability, qui dépend du mode de liaison. "OneWay" exige seulement que la propriété peut être lu, "Bidirectionnels" nécessite la lecture et de l'écriture, et "OneWayToSource" ne nécessite qu'une écriture de la propriété. Anonyme, les classes ne pas inplement IPropertyChangeNotifier, donc WPF n'est pas automatiquement informés sur le changement, mais en fonction de l'utilisation qui peut ne pas être un problème, et WPF peut toujours être manuellement la consigne de les relier. Dans de nombreuses applications à la fois une source de données est lié à tous les autres accès se produit sur le thread de l'INTERFACE utilisateur, ainsi, éviter l'accès simultané préoccupations.

    InformationsquelleAutor Eric Lippert
  3. 3

    Vous ne pourrez pas obtenir le bon syntaxe d'initialisation, mais le ExpandoObject classe introduit dans .NET 4 servirait comme une solution viable.

    dynamic eo = new ExpandoObject();

eo.SomeIntValue = 5;
eo.SomeIntValue = 10; //works fine
    • Je ne pense pas que ExpandoObject prend en charge un nom, tapé, null valeur de la propriété (puisqu'il s'agit seulement d'un dictionnaire, et tous les null valeurs typées), tandis qu'un type anonyme n'.
    InformationsquelleAutor AnthonyOSX
  4. 3

    En C# 7 on peut tirer parti de nommé tuples de faire le tour:

    (bool a, bool b) myVar = (false, true);

if (myVar.a)
{
    myVar.b = true;
}
    • 🙁 J'espérais que je pourrais utiliser cette fonction en C# 6, je crois que je suis hors de la chance pour mon projet en cours... (Sauf si je peux convaincre certaines personnes de mise à niveau)
    InformationsquelleAutor Kees C. Bakker
  5. 2

    Pour les types ci-dessus de l'opération, vous devez définir votre propre mutable STRUCT. Mutable structures peuvent poser un casse-tête pour les rédacteurs du compilateur comme Eric Lippert, et il y a quelques malheureux limitations comment .net poignées, mais la sémantique de mutables "Plain Old Données" des structures (structures dont tous les champs sont publiques, et la seule fonction publique qui écrire this sont les constructeurs, ou sont appelés exclusivement à partir de constructeurs) offre la mesure de la sémantique que ce qui peut être réalisée par des classes.

    Par exemple, considérez les points suivants:

    struct Foo { 
public int bar; 
...d'autres choses; 
} 
int test(Action<Foo[]> proc1, Action<Foo> proc2) 
{ 
foo myFoos[] = new Foo[100]; 
proc1(myFoos); 
myFoos[4].bar = 9; 
proc2(myFoos[4]); //Passage par valeur 
retour myFoos[4].bar; 
}

    En supposant que il n'y a pas de code non sécurisé et que le passé-les délégués peuvent être appelés, et sera de retour en un temps fini, ce sera test() retour? Le fait que Foo est une structure avec un champ public bar est suffisante pour répondre à la question: il sera de retour 9, indépendamment de ce qui apparaît dans la déclaration de Foo, et indépendamment de ce que les fonctions sont passés dans proc1 et proc2. Si Foo étaient une classe, il faudrait examiner chaque Action<Foo[]> et Action<Foo> qui existe ou existera jamais, de savoir ce que test() serait de retour. La détermination de cette Foo est une structure publique de champ bar semble beaucoup plus facile que l'examen de tout passé et de l'avenir des fonctions qui pourraient se passer dans.

    Struct méthodes qui modifient this sont traitées particulièrement mal .net, donc si on a besoin d'utiliser une méthode pour modifier un struct, c'est presque certainement préférable d'utiliser l'un de ces modèles:

     myStruct = myStruct.ModifiedInSomeFashion(...); //Approche #1 
myStructType.ModifyInSomeFashion(réf myStruct, ...); //Approche #2

    que le motif:

     myStruct.ModifyInSomeFashion(...);

    Pourvu que l'on emploie l'approche ci-dessus pour struct-la modification des modèles, cependant, mutable structures ont l'avantage de permettre de code qui est à la fois plus efficace et plus facile à lire que des structures immuables, ni immuable classes, et est beaucoup moins de problèmes vulnérables que mutable classes. Pour les choses qui représentent une agrégation de valeurs, sans identité, à l'extérieur les valeurs qu'elles contiennent, mutable types de classes sont souvent les pires représentation possible.

    • "La sémantique" est de toute évidence dans l'œil de celui qui regarde, mais je suis en désaccord leurs structures avec tous les membres de répondre à l'attente de beaucoup les programmeurs débutants. La sémantique d'une mutable struct passé par valeur a beaucoup de petits pièges, comme indiqué par la obtus modifier le modèle recommandé dans cette réponse. Champs publics se différencie également de la structure de l'encapsulation, qui est l'un des principaux avantages de la programmation orientée objet. Aller avec Eric et de l'autre langue designers sur celui-là -- il suffit de ne pas le faire.
    • Une structure avec des champs publics se comporte essentiellement comme un tas de sites de stockage, collées avec du ruban adhésif. Dans les cas où l'on veut coller un tas de sites de stockage, ensemble avec du ruban adhésif, le code à l'aide qui utilise BoSLSTwDT (struct) sera plus clair que le code qui essaie d'utiliser un autre type de simulation. La principale chose qui rend les structures de confusion est l'effort par la langue de prétendre qu'ils sont une forme de Object.
    InformationsquelleAutor supercat