StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>Why did the BCL team decide on not allowing changes to the <em>value</em> when looping over dictionary. I understand that the <em>key</em> cannot be changed but why not allow changes to the value?</p> </blockquote> <p>I cannot speak <em>definitively</em> for the team which built the dictionary, but I can make some educated <em>guesses</em>. </p> <p>First, it is often said that good programs are strict about the correctness of their outputs, but forgiving in what they accept. <em>I do not believe this to be a good design principle.</em> This is a <em>bad</em> design principle because it allows <em>buggy callers</em> to take <em>dependencies</em> on <em>undefined</em> and <em>unsupported</em> behaviour. It thereby creates a backwards-compatibility burden. (We certainly see this in the web browser world, where every browser vendor is pressured to be compatible with every other browser's acceptance of incorrect HTML.) </p> <p>Components define contracts -- they say what information they accept as input, what operations they support, and what results they produce. When you accept inputs that are not in your contract, or support operations that are not in your contract, what you're doing is essentially making a <em>new</em> contract, a contract which is not documented, not supported, and could be broken in a future version. You're basically building a time bomb and when it goes off, either a customer (who probably didn't even know that they were doing something unsupported) gets broken, or the component provider ends up having to support forever a contract that they didn't actually sign up for.</p> <p>It is therefore a good design principle to <em>strictly enforce your contract</em>. The contract of IEnumerable on a collection is "it's illegal to modify the collection while iterating". An implementer of this contract can choose to say "well, I happen to know that certain modifications are safe, so I'll allow those", and hey, suddenly you're not implementing the contract anymore. You're implementing a different, undocumented contract that people will come to rely on.</p> <p>It is better to simply <em>enforce</em> the contract, even if that's unnecessary. That way, in the future, you have the freedom to rely upon your documented contract without worrying that some caller has broken the contract and gotten away with it, and expects to continue to be able to do so forever.</p> <p>It would be easy to design a dictionary that allowed mutation of values during iteration. Doing so prevents the component providers from ever being able to turn that feature off, and they are not required to provide it, so it is better to give an error when someone tries than to allow a caller to violate the contract.</p> <p>Second guess: the dictionary type is unsealed, and therefore can be extended. Third parties might extend the dictionary in such a manner that their invariants would be violated if a value were changed during an enumeration. Suppose, for example, that someone extends a dictionary in such a manner that it can be enumerated <em>sorted by value</em>. </p> <p>When you write a method that takes a Dictionary and does something to it, you assume that the operation will work on <em>all dictionaries</em>, even third party extensions. The designers of a component that is intended for extension need to be even more careful than usual to ensure that the object enforces its contract, because unknown third parties might be relying upon the enforcement of that contract. Because there <em>might</em> be a dictionary that <em>cannot</em> support changing a value during iteration, the base class should not support it either; to do otherwise is to violate the substitutability of derived classes for base classes.</p> <blockquote> <p>Also if you are using LINQ and getting the keys back in form of IEnumerable, can the value be changed ?</p> </blockquote> <p>The rule is that a dictionary may not be changed while iterating over it. Whether you're using LINQ to do the iteration or not is irrelevant; iteration is iteration.</p> <blockquote> <p>does lazy loading have a role to play?</p> </blockquote> <p>Sure. Remember, defining a LINQ query does not iterate over anything; the result of a query expression is a query object. It is only when you iterate over that object that the actual iteration happens over the collection. When you say:</p> <pre><code>var bobs = from item in items where item.Name == "Bob" select item; </code></pre> <p>no iteration happens here. It's not until you say</p> <pre><code>foreach(var bob in bobs) ... </code></pre> <p>that iteration over items happens.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload