Panopticon Central

a blog on Visual Basic, .NET and other stuff

  Home :: Contact :: Syndication  :: Login
  492 Posts :: 19 Stories :: 3298 Comments :: 628 Trackbacks

News

The information in this weblog is provided "AS IS" with no warranties, and confers no rights.

My Book

Picture

My Recent Posts

Article Categories

Archives

Post Categories

Microsoft Blogs

Samples

Technical Blogs

VB Links

About a month ago, the C# team announced that they were making anonymous types immutable in C# 9.0. The issues with mutable anonymous types are pretty well described in Sree's blog entry, but what it boils down to is this: in several places in LINQ, anonymous types are used as keys for things like grouping and filtering. For example, if you group customers by state and country, then the grouping is done on a composite key made up of the State field and the Country field in an anonymous type. To enable keys to be used to do grouping efficiently, they have to expose a stable hash value. That is, once a key has been constructed, it always needs to return the same hash value.

The problem was that anonymous types base their hash value on the hash values of the constituent members of the type. If those values are mutable, then that means that the hash value is mutable. Which means that the hash value might not be stable, which means that it might be possible to really hork up LINQ queries by accidentally changing keys during an operation.

In looking at this problem, though, we didn't want to throw the baby out with the bathwater. Anonymous types are somewhat limited at the moment because they cannot be named, but you can use late binding to work with them even outside of the context in which they were declared. And future features that we're interested in exploring, such as nominal anonymous types and dynamic interfaces, may make anonymous types even more useful. As such, it seemed too drastic to simply make them immutable, especially because this would be a one-way decision--once they were immutable, compatibility would make it extremely difficult to make them mutable again in the future if it become more desirable to do so.

At the same time, it occurred to us that the problem we're dealing with here--generating hash values--is one that applies to many situations, not just anonymous types. Generating hash values is a common operation for types, and making it easier to do that right seemed to be a win. So instead of changing the way anonymous types work, we'll be introducing in Beta 2 a way to more easily generate a correct hash value from a type. For Orcas, this will be limited to anonymous types, but beyond Orcas, we'd like to generalize this to all types.

In Beta 2, you will be able to specify a Key modifier on a field of an anonymous type (i.e. "New With { Key .Country = "USA", Key .State = "WA" }"). This modifier will do two things: one, it will make the field read-only (since keys have to be stable), and two, it will cause GetHashCode to be overridden and call the GetHashCode of the key field. You can have as many Key fields as you like, and the hash codes of all the keys will be combined. The LINQ query expressions will automatically use Key fields in any situation where a key is going to be generated (for example, Group By), but you will need to include the Key modifier if you are calling the LINQ APIs directly. Post-Orcas, we'd like to generalize this concept to all types and allow you to declare Key properties or fields, and do the same thing as with anonymous types. This will, we hope, simplify the work of making types that can be easily hashed.

posted on Friday, May 11, 2007 12:13 PM

Feedback

# re: Mutable and immutable anonymous types, and keys 5/11/2007 1:23 PM Fabrice
Does that mean that instances of anonymous types will be mutable again in beta 2?

# Anonymous method remain mutable in VB. 5/11/2007 7:52 PM @ Head
Paul Vick posted that anonymous types will remain mutable in VB . Generally this looks good, I just hope

# re: Mutable and immutable anonymous types, and keys 5/12/2007 12:13 AM Matt Warren
The real problem with mutable types and hashcodes was not any interference with LINQ, but with Hashtables/Dictionaries and DataBinding. If the anonymous types were data-bound and the fields were allowed to be editted the 'hashcodes' would change to make the new values and the object would no longer be discoverable within the table.

# Interesting Finds: May 12, 2007 5/12/2007 11:09 AM Jason Haley


# re: Mutable and immutable anonymous types, and keys 5/13/2007 2:22 PM Daniel Moth
I don't think we have made our messaging clear here. This "Key" functionality described in this post is not mentioned in the older C# post. Is the implementation different in the two languages then?

# re: Mutable and immutable anonymous types, and keys 5/14/2007 3:41 PM Mike Schinkel
I really don't follow. Can you give an example of where the problem occurs? Both for mutable and immutable?

# VB.NET to the rescue 5/14/2007 4:58 PM Claudio Brotto
Ho sempre sostenuto che VB.NET fosse un linguaggio creato più per ragioni di mercato che per reali necessità

# re: Mutable and immutable anonymous types, and keys 5/14/2007 9:28 PM Fan
Oh! You've done a great thing!! Generating hashcode is previously a complex work and easily to be done incorrectly.
I fully support this design.

# re: Mutable and immutable anonymous types, and keys 7/19/2007 10:16 PM kris
I avoid hash code. Hope this feature makes it easier ...

do post an example.

K r i s
http://www.vkinfotek.com

# Lambdas, and Take While, and Group By, Oh My! 7/26/2007 5:18 PM The Visual Basic Team
Hooray! Visual Basic 2008 Beta2 has been released to the wild today to return to its natural habitat

Post Feedback

Title:
Name:
Url:
Comments: