Freigeben über

News flash: Instances of anonymous types will be immutable

  • Artikel

I've been meaning to write a blog post about a recent design change that we've made here on the C# team. As you may have gathered from my previous posts, we are introducing anonymous tuple types in C# 3.0. We've recently decided to make instances of those tuple types immutable; once you construct a particular instance, it is stuck with those values forever.

There are a lot of good reasons to make tuples immutable: it ensures that they have stable hash codes, functional-style programming works better on immutable objects (functional programming is all about avoiding side effects; mutating state is a side effect) and concurrent programming works better on immutable objects.

So anyway, I was going to write this big long blog post about all these things, but I don't have to because the guy across the hall from me, Sreekar Choudhary, has started blogging. Sree is our local expert on anonymous types, extension methods and everything to do with the expression evaluator that runs in the debugger (ie, the watch window.) I'm looking forward to seeing what he has to talk about in his new blog.

Comments

  • Anonymous
    April 13, 2007
    So will there be any adjustments to the object initializer semantics that will allow normal (non-anonymous) classes to benefit from the changes towards immutability. c.f. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=245342&SiteID=1

  • Anonymous
    April 13, 2007
    The comment has been removed

  • Anonymous
    April 13, 2007
    Hi Andrew, not sure why you consider some language support for immutability a "minimal payoff", nor how you come to evaluate that it would take "quite a bit of work". You also missed the point, which was some language support for immutability, with a side benefit of behaving somewhat like named parameters. Immutability combined with property initializers was the goal, something that isnt possible now, but with the changes eric mentioned, might have a pleasing symetry if supported beyond just anonymous classes.

  • Anonymous
    April 13, 2007
    I agree with andrew that making anonymous types always immutable is like throwing the baby out with the bathwater. Both mutable and immutable anonymous types should be supported.

  • Anonymous
    April 13, 2007
    OK, how would you implement GetHashCode on a mutable anonymous type? It's all very well for you guys to theorize about what is and isn't a lot of work for me to do; I'd like to take this opportunity to point out that Sree and I are the ones who actually DO the work, and there are only so many hours in the day.   Assuming that you can come up with a design for mutable anonymous types which doesn't violate framework design guidelines for GetHashCode, the next thing to consider is "what features would you like to see cut so that we have time to implement and test mutable anonymous types?"

  • Anonymous
    April 13, 2007
    GetHashCode should behave for mutable anonymous types as it does for every other mutable type - it should only be a valid operation as long as the instance isnt modified. That means theres no language enforced guarantees. I would implement it as object identity for mutable types (or simply throw an InvalidOperation exception), and for immutable types, I would implement it as you have done. Sometimes I have have the first call to GetHashCode transform my types into an immutable or frozen state. Personally, I think making GetHashCode a method of every single object instance was a mistake. Some classes just arent meant to be used as keys in a dictionary. Its only because we love your work that we want to much from you :)

  • Anonymous
    April 13, 2007
    The comment has been removed

  • Anonymous
    April 13, 2007
    The comment has been removed

  • Anonymous
    April 14, 2007
    I'm not arguing the benefits of immutability - it leads to completely declarative languages which are a Good Thing(TM). I'm not even really arguing whether anonymous tuples should be immutable or mutable - that decision has already been made, and there's no reason to revisit it because of some anonymous comments on Eric's blog. My only "curiousity" at this point is whether the change actually accomplishes the desired result. i.e., If a read-only tuple contains references to mutable objects, can it really be considered to be immutable?

  • Anonymous
    April 16, 2007
    The comment has been removed

  • Anonymous
    May 28, 2007
    One of the recent changes we made to anonymous types was to allow the syntax to convey the notion of