C# et immuabilité et champs de lecture ... un mensonge?

EDIT: je me suis concentré sur le code travaillant "à l'intérieur" du système par opposition à l'utilisation de la réflexion etc comme Eric le mentionne.

cela dépend du type de champ. Si le champ lui-même est d'un type immuable (par exemple String ) alors c'est très bien. Si c'est StringBuilder alors l'objet peut apparaître pour changer même si les champs eux-mêmes ne changent pas leurs valeurs, parce que les objets" embedded " peuvent changer.

Les types anonymes sont exactement les mêmes. Par exemple:

var foo = new { Bar = new StringBuilder() };
Console.WriteLine(foo); // { Bar = }
foo.Bar.Append("Hello");
Console.WriteLine(foo); // { Bar = Hello }

donc, fondamentalement si vous avez un type que vous voulez être correctement immuable, vous devez vous assurer qu'il se réfère uniquement à des données immuables.

il y a aussi la question des structures qui peuvent avoir des champs lisibles mais qui exposent encore des méthodes qui se mutent en réassignant this . De telles structures se comportent un peu étrangement selon la situation exacte dans laquelle vous les appelez. Pas sympa - ne pas le faire.

Eric Lippert a écrit un beaucoup de choses sur l'immuabilité - c'est tout en or, comme vous pouvez vous y attendre... allez lire :) (Je n'avais pas remarqué Qu'Eric écrivait une réponse à cette question lorsque j'ai écrit ce passage. Évidemment lire sa réponse aussi!)

je pense que la réponse D'Eric dépasse de loin la portée de la question initiale, au point de ne même pas y répondre, alors je vais tenter ma chance:

quoi est seulement? Eh bien, si nous parlons de types de valeurs, c'est simple: Une fois que le type de valeur est initialisé et qu'on lui donne une valeur, il ne peut jamais changer (du moins en ce qui concerne le compilateur).

la confusion commence à s'installer lorsque nous parlons d'utiliser readonly avec les types de référence. C'est à ce stade que nous devons distinguer les deux composantes d'un type de référence:

• la "référence" (variable, pointeur) qui pointe vers l'adresse en mémoire où vit votre objet
• la mémoire qui contient les données que la référence pointe à

une référence à un objet est elle-même un type de valeur. lorsque vous utilisez readonly avec un type de référence, vous faites référence à votre objet immuable, ne forçant pas l'immutabilité sur la mémoire dans laquelle l'objet vit.

considérez maintenant un objet qui contient des types de valeurs et des références à d'autres objets, et ces objets contiennent des types de valeurs et des références à d'autres objets. Si vous composez vos objets de manière à ce que tous les champs de tous les objets soient lisibles, vous pouvez, en essence, atteindre l'immuabilité que vous désirez.

Readonly et Thread Safety sont deux notions différentes comme Eric Lippert l'explique.

peut-être que le "peuple" avait entendu de la 3e main et avait mal communiqué au sujet du privilège spécial que le constructeur obtient en ce qui concerne les domaines "en lecture seule". Ils ne sont pas en lecture seule.

non seulement ça, mais ce n'est pas une seule affectation. Le constructeur d'une classe peut modifier le champ autant de fois qu'il le souhaite. Tout cela sans enfreindre aucune"règle".

peuvent aussi appeler d'autres méthodes arbitraires, se passant eux-mêmes comme paramètres. Donc, si vous êtes cette autre méthode, vous ne pouvez pas être certain si ce champ est encore immuable, parce que peut-être vous avez été invoqué par le constructeur de cet objet, et le constructeur va modifier le champ dès que vous avez terminé.

Vous pouvez essayer vous-même:

using System;
class App
{
    class Foo 
    {
        readonly int x;
        public Foo() {  x = 1; Frob(); x = 2; Frob(); }
        void Frob() { Console.WriteLine(x); }
    }
    static void Main()
    {
        new Foo();
    }
}

ce programme imprime 1, 2. 'x' est modifié après que Frob l'ait lu.

maintenant, dans n'importe quel corps de méthode simple, la valeur doit être constante -- le constructeur ne peut pas delegate modify-accès à d'autres méthodes ou délégués, donc jusqu'à ce qu'une méthode revienne, Je suis presque sûr que le champ devra rester stable.

Tout ce qui précède concerne les classes. Les structures sont une toute autre histoire.