Anonymous types properties are read-only - by Christian Liensberger - INACTIVE

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 294257 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 8/20/2007 2:27:43 PM
Access Restriction Public

Description

I need to access the properties of an anonymous type during runtime. Not only read them but also write them. But they are ready only. Only getter and the fields are also readonly.
Sign in to post a comment.
Posted by Microsoft on 4/24/2008 at 4:41 PM
Thanks again for your suggestion. After having done feature planning for the next release of C# I regret to say that this feature is not being added. We have to do some harsh prioritization, both because of our implementation and testing resources, but also because we need to keep the number of new langauge features at a manageable level - depending on how you count, we are adding only four language features to C# this time around. Unfortunately many great suggestions just can't make it in because of that.

I apologize that this is a "canned" follow-up answer, sent out as a result of our feature planning for the next release. In most cases I or someone else already replied individually to your suggestion - please let us know if you feel it hasn't been adequately addressed.

Thanks again for taking the time to share your ideas with us. Please keep them coming!

Mads Torgersen, C# Language PM.
Posted by Microsoft on 9/7/2007 at 4:21 PM
We may look at VB-like keys in the next version of C#, but that is very tentative.
Posted by Christian Liensberger - INACTIVE on 9/6/2007 at 4:01 AM
What about this idea to provide keys: http://www.panopticoncentral.net/archive/2007/05/11/20566.aspx

And perhaps if nothing is specified as key make everything immutable...
Posted by Christian Liensberger - INACTIVE on 8/30/2007 at 1:13 PM
Hi Mads,

could you send me an e-mail. I need to ask you something that has nothing to do with this problem... christian@liensberger.it would be my e-mail handle. Thanks!
Posted by Microsoft on 8/30/2007 at 12:59 PM
That seems to be the way forward, yes - it is also what we do in LINQ to SQL. Note that anonymous types have special representation in our expression trees so that you can do this easily.

Mads
Posted by Christian Liensberger - INACTIVE on 8/30/2007 at 12:48 PM
Thank you for your reply! :) I'll try to implement it in a way to have the anonymous type populated via the constructor in my O/RM.

Thanks again!
Posted by Microsoft on 8/30/2007 at 12:40 PM
It is leaky. You create an object and put it in a hashtable. You change it and loose contact with it - even if you remove the same object, the removal fails. Thus, you have things sitting around in there forever. In a dictionary, not just the keys but the keyed values are artificially kept alive.

Yes the right amount of discipline across an application can avoid this kind of thing, but would you as the table owner trust me as the data owner never to change it? Only if I can't. It's a contract thing.

We had this issue for real: first off we designed anonymous types to be mutable. Databinding guys got upset because you could display an anonymous value to a user, they could change it, and the internal bookkeeping coudl get messed up. At the end of the day we decided that the value equality was more important than the mutability, and changed the design in that direction.

Thanks again,

Mads
Posted by Christian Liensberger - INACTIVE on 8/30/2007 at 3:22 AM
OK! I haven't seen the custom implementation of GetHashCode. What you say makes sense, since you do a value comparison. But I have one question left: why doesn't the hashcode just change if I change the members and that's it? I mean if I change the members and I try to search with the old values it just doesn't return it. It is my problem that I changed the values... Is that to complex for the end-user?
Posted by Microsoft on 8/29/2007 at 1:51 PM
Thanks for your feedback.

This is by design. Anonymous types are designed to have Equals and GetHashCode based on their members; i.e. what we call value based equality. This is important for their use as composite keys in central LINQ scenarios for instance. However, value-based equality is only sound for reference types if those types are immutable. Otherwise how would you stick them in a hashtable and expect to find them again?

If you need a mutable type, auto-implemented properties now make it a lot easier for you to create as a named class.

Thanks again,

Mads Torgersen, C# Language PM
Posted by Microsoft on 8/21/2007 at 4:00 AM
Thanks for your feedback. We have reproduced this bug on Visual Studio 2008 Beta 2, and we are sending this bug to the appropriate group within the VisualStudio Product Team for triage and resolution.

Thank you,
Visual Studio Product Team.
Posted by Microsoft on 8/20/2007 at 8:07 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com). Thank you, Visual Studio Product Team.