As it stands, its not possible to create structs using the anonymous type mechanism. Its also not possible to create immutable anonymous types.
Id like to suggest the following syntax:
// a mutable anonymous class
var a = new { X = 1, Y = 2};
// a mutable anonymous struct
var b = new struct { X = 1, Y = 2 };
// an immutable anonymous class
var c = new readonly { X = 1; Y = 2};
// an immutable anonymous struct
var d = new readonly struct { X = 1; Y = 2};
sugegstions for anonymous types
Hot Topic
- Many Package Load Failures with Beta2
- How access to a connector property
- table of data
- How to update PropertyGrid after changing type
- Package "Visual Studio Common IDE Package" failed to load
- Publish GridView in Avalon as DataGridView?
- could not load type Microsoft.VisualStudio.CommonIDE.TemplateWizard.Wizard
- FatalExecution error when applying Setter to Window
- Crystal report in vb 2005 express
- General Questions
Visual Studio
- Difficult to Layout InfoPath Forms
- Exec task with ContinueOnError=true
- Problem with Cider and Sparkle on Vista Build 5342
- JOINS
- Functions in MSBuild
- MFC work around Avalon control
- Add-In registration in VS 2005 Beta 2
- Release Date
- a problem with Exec function
- Microsoft Word 2003 and WordML (How to Show/Hide Content in a Document)?
sugegstions for anonymous types
Scott Simmer
One thing also to keep in mind is that this is purely a C# matter. Other languages may deal with anonymous types if they so choose, and may do so with different rules.
Gotta love .NET :)
C K Legan
Hi Damien,
Thanks for your suggestion.
Anonymous types are kind of annoying from a language designer's perspective, because they seem to constantly "cry for more". As a matter of fact we are trying to keep them down to the bare minimum needed for the common-case convenience they are created for (they also make life easier for database integration in DLinq). Our current policy is that whenever people wish to step outside of that, they should create a named type. Instead VS Orcas will provide tool support to refactor anonymous types into named ones, so that the upgrade experience is smooth.
You won't believe how many roads we've been down starting with adding a little extra to anonymous types and ending with a whole new type concept.
On your specific proposal, I think that
a) we specifically do not want to encourage structs in this situation. Objects are almost always better, and for the few situations where there is a significant performance gain, people can write the named type
b) readonly is not a priority for anonymous types, as they are only used locally, so we do not need to prevent "others" from modifying them. There is a marginal gain perhaps in being protected from "yourself"; again in cases where that is crucial, it is probably better to have an explicit named type.
It is great with this kind of proposal, though, it does sharpen our reasoning about the design, and oftentimes proposals do influence the design, so - keep'em coming!
Thanks,
CentrixGuy
Stage
I agree that adding "a little bit extra" to anonymous types can be an open ended activity. My initial thoughts on ways of extending anonymous types were along the lines of providing a function that generate anonymous types based on the property names and types, along with other (constant) data (much like attributes are generated based on constant data). One could imagine an anonymous type that implements INotifyPropertyChanged, for example. I felt that that proposal was a bit too "out there", and settled on struct and readonly types as a non-invasive set of variants.
You talk of a goal of supporting DLinq, but DLinq is but one part of Linq, albeit the main one you guys are working on. I being up these matters because they are issues I struggle with while working on my own Linq system (The details of which I would be happy to discuss with you in private email).
My response to your specific points:
a) Im not convinced that objects are almost always better. For a highly pipelined architecture such as that encouraged by the monoid comprehension nature of Linq, the use of structs can prevent allocations along many stages of the pipeline. There will certainly be times when it is _more_ efficient to use structs rather than classes.
b) Im also not convined that anonymous types will only be used locally. You're anticipating that anonymous types will only be used in Linq, and then only internally to queries. However, anonymous types will become part of the language as a whole, and I doubt that anyone could anticipate what kinds of uses they will be put to. What I do know is that when code expects a type to be immutable, and it is not, its a hellish kind of bug to track down.
msucre