Dynamic in C# 4.0: Introducing the ExpandoObject

Articolo
09/30/2009

You have probably already heard about the new dynamic feature in C# 4.0 and how it is used to support COM interop. If you haven't, I strongly recommend reading the following MSDN articles: Using Type dynamic and How to: Access Office Interop Objects by Using Visual C# 2010 Features.

Well, where else can you use this new feature? What are the use cases? Where does dynamic dispatch work better than static typing?

The quick answer is that whenever you see syntax like myobject.GetProperty("Address"), you have a use case for dynamic objects. First of all, the above syntax is difficult to read. Second, you don’t have any IntelliSense support for the property name, and if the “Address” property doesn’t exist you get a run-time exception. So why not create a dynamic object that calls the property as myobject.Address? You still get the run-time exception, and you still don't get IntelliSense, but at least the syntax is much better.

In fact, it’s not just better syntax. You also get flexibility. To demonstrate this flexibility, let’s move to ExpandoObject, which is a part of the new dynamic language runtime (DLR). ExpandoObject instances can add and remove members at run time. Where can you use such an object? XML is a good candidate here.

Here’s a code example that I took from MSDN. (Yes, I am an MSDN writer myself, so I use MSDN a lot.)

 XElement contactXML =
    new XElement("Contact",
        new XElement("Name", "Patrick Hines"),
        new XElement("Phone", "206-555-0144"),
        new XElement("Address",
            new XElement("Street1", "123 Main St"),
            new XElement("City", "Mercer Island"),
            new XElement("State", "WA"),
            new XElement("Postal", "68042")
        )
    );

Although LINQ to XML is a good technology and I really love it, those new XElement parts look a little bit annoying. This is how I can rewrite it by using ExpandoObject.

 dynamic contact = new ExpandoObject();
contact.Name = "Patrick Hines";
contact.Phone = "206-555-0144";
contact.Address = new ExpandoObject();
contact.Address.Street = "123 Main St";
contact.Address.City = "Mercer Island";
contact.Address.State = "WA";
contact.Address.Postal = "68402";

Just note a couple of things. First, look at the declaration of contact.

dynamic contact = new ExpandoObject();

I didn’t write ExpandoObject contact = new ExpandoObject(), because if I did contact would be a statically-typed object of the ExpandoObject type. And of course, statically-typed variables cannot add members at run time. So I used the new dynamic keyword instead of a type declaration, and since ExpandoObject supports dynamic operations, the code works.

Second, notice that every time I needed a node to have subnodes, I simply created a new instance of ExpandoObject as a member of the contact object.

It looks like the ExpandoObject example has more code, but it’s actually easier to read. You can clearly see what subnodes each node contains, and you don’t need to deal with the parentheses and indentation. But the best part is how you can access the elements now.

This is the code you need to print the State field in LINQ to XML.

 Console.WriteLine((string)contactXML.Element("Address").Element("State"));

And this is how it looks with ExpandoObject.

 Console.WriteLine(contact.Address.State);

But what if you want to have several Contact nodes? Like in the following LINQ to XML example.

 XElement contactsXML =
    new XElement("Contacts",
        new XElement("Contact",
            new XElement("Name", "Patrick Hines"),
            new XElement("Phone", "206-555-0144")
        ),
        new XElement("Contact",
            new XElement("Name", "Ellen Adams"),
            new XElement("Phone", "206-555-0155")
        )
    );

Just use a collection of dynamic objects.

 dynamic contacts = new List<dynamic>();

contacts.Add(new ExpandoObject());
contacts[0].Name = "Patrick Hines";
contacts[0].Phone = "206-555-0144";

contacts.Add(new ExpandoObject());
contacts[1].Name = "Ellen Adams";
contacts[1].Phone = "206-555-0155";

Technically speaking, I could write dynamic contacts = new List<ExpandoObject>() and the example would work. However, there are some situations where this could cause problems, because the actual type of the list elements should be dynamic and not ExpandoObject, and these are two different types. (Once again, references to the ExpandoObject objects are statically-typed and do not support dynamic operations.)

Now, if you want to find all the names in your contact list, just iterate over the collection.

 foreach (var c in contacts)
    Console.WriteLine(c.Name);

Again, this syntax is better than LINQ to XML version.

 foreach (var c in contactsXML.Descendants("Name"))
    Console.WriteLine((string)c);

So far, so good. But one of the main advantages of LINQ to XML is, well, LINQ. How would you query dynamic objects? Although there is still a lot to be done in this particular area, you can query dynamic objects. For example, let’s find all the phone numbers for the specified name.

 var phones = from c in (contacts as List<dynamic>)
             where c.Name == "Patrick Hines"
             select c.Phone;

True, the cast here doesn’t look like something strictly necessary. Certainly the compiler could have determined at run-time that contacts is List<dynamic>. But as I said, there is still some work to be done in this area.

Another thing to note is that this trick works only for the LINQ to Objects provider. To use dynamic objects in LINQ to SQL or other LINQ providers, you need to modify the providers themselves, and that’s a completely different story.

However, even with the cast, syntax is still better than in a LINQ to XML query.

 var phonesXML = from c in contactsXML.Elements("Contact")
                where c.Element("Name").Value == "Patrick Hines"
                select c.Element("Phone").Value;

Sure, there are some things that look better in LINQ to XML. For example, if you want to delete a phone number for all the contacts, you can write just one line of code in LINQ to XML.

 contactsXML.Elements("Contact").Elements("Phone").Remove();

Since C# doesn’t have syntax for removing object members, you don’t have an elegant solution here. But ExpandoObject implements IDictionary<String, Object> to maintain its list of members, and you can delete a member by deleting a key-value pair.

 foreach (var person in contacts)
    ((IDictionary<String, Object>)person).Remove("Phone");

There are other useful methods in LINQ to XML like Save() and Load(). For ExpandoObject you need to write such methods yourself, but probably only once. Here, casting to the IDictionary interface can help as well.

And although I’ve been comparing LINQ to XML and ExpandoObject in this post, these two approaches are not “rivals”. You can convert ExpandoObject to XElement and vice versa. For example, this is what the ExpandoObject to XElement conversion might look like.

 private static XElement expandoToXML(dynamic node, String nodeName)
{
    XElement xmlNode = new XElement(nodeName);

    foreach (var property in (IDictionary<String, Object>)node)
    {

        if (property.Value.GetType() == typeof(ExpandoObject))
            xmlNode.Add(expandoToXML(property.Value, property.Key));

        else
            if (property.Value.GetType() == typeof(List<dynamic>))
                foreach (var element in (List<dynamic>)property.Value)
                    xmlNode.Add(expandoToXML(element, property.Key));
            else
                xmlNode.Add(new XElement(property.Key, property.Value));
    }
    return xmlNode;
}

This little trick might help you access all the LINQ to XML functions when you need them but at the same time use more convenient syntax when creating and modifying XML trees.

Of course, XML is not the only area where you can use ExpandoObject. If you heavily use reflection or work a lot with script objects, you can simplify your code with ExpandoObject. On the other hand, ExpandoObject is not the only useful class that the DLR provides. The DynamicObject class, for example, enables you to take more control over dynamic operations and define what actually happens when you access a member or invoke a method. But that’s a topic for another blog post.

One more thing to note is that libraries that look up members by name might someday adopt the DLR and implement the IDynamicMetaObjectProvider interface. (This interface actually provides all the “magic” – or dynamic dispatch – for ExpandoObject and the dynamic feature in general.) For example, if LINQ to XML implements this interface, you would be able to write dynamic contacts = new XmlElement() instead of dynamic contacts = new ExpandoObject() and perform the same operations that I have shown in the examples for the ExpandoObject type.

All the examples provided in this blog post work in Visual Studio 2010 Beta 1. If you have any comments or suggestions, you are welcome to post them here or contact the DLR team at https://www.codeplex.com/dlr. You can also write an e-mail to the DLR team at dlr@microsoft.com.

Update:

See how you can improve this example in my next post: Dynamic in C# 4.0: Creating Wrappers with DynamicObject.

Comments

Anonymous
October 01, 2009
For this use case, wouldn't it be neater to make a wrapper class that implements IDynamicMetaObjectProvider by directly forwarding into an XElement? That way there is no need to build up the structure in a hierarchy of ExpandoObjects and then later need to do a full recursive copy when you want an XElement tree - it would already be an XElement tree.
Anonymous
October 01, 2009
Why not just declare contacts as var or List<dynamic>? Does it need to be declared dynamic? Then it could be passed into LINQ contexts without casts. Also, it'd be nice to have syntax such as contacts.Add(new ExpandoObject() as dynamic { Name = "Eric" });
Anonymous
October 01, 2009
Niiice. I was wondering once upon a time if that would be possible. Thanks for sharing.
Anonymous
October 02, 2009
The dynamic enhancements to C# are bringing me back to the language. I've haven't been really excited about anything new in .Net since 2.0 - LINQ seemed (to me) to be a solution in search of a problem - but now I'm really looking forward to using 4. Since falling in love with dynamic languages like javascript, python and PHP I've felt like C# was really lagging behind. It looks like these new features will combine the best of both worlds: the power and maturity of the .Net framework and the flexibility and productivity of dynamic languages. Thank you!
Anonymous
October 02, 2009
Daniel, Implementing IDynamicMetaObjectProvider is a challenging task. And I wanted to provide a simple example that people can use right away. If LINQ to XML decides one day to support this type of syntax, they will probably need to implement this interface. But defenitely it's not a task for people who just use this library. By the way, ExpandoObject already implements IDynamicMetaObjectProvider. Otherwise none of those features would be possible. But you are right about the wrapper. For this particular example, it is actually a better way to do things. But instead of implementing IDynamicMetaObjectProvider, you can use the DynamicObject class (which, again, already implements this interface). I am planning another blog post about the DynamicObject class, where I'll show how you can do it. The idea of this blog post was to introduce the new dynamic features in an easy-to-understand and easy-to-try way. I hope that it is clear that ExpandoObject is not limited to XML. You can sometimes use it instead of anonymous types, for example.
Anonymous
October 02, 2009
The comment has been removed
Anonymous
October 02, 2009
This is pretty cool stuff. In addition to dynamically generated properties, the ExpandoObject will also let you define runtime generated methods quite easily. For example: public static void Main(string[] args) { dynamic dynamicXml = new ExpandoObject(); dynamicXml.DoSomething = new Action<string>(s => { Console.WriteLine(s); }); dynamicXml.DoSomething("Hello World!"); Console.ReadLine(); } I was also trying to figure out a way to create run-time generated events, but have so far been unsuccessful. If anybody has any ideas on how to do that, I would be interested.
Anonymous
October 02, 2009
Chris, You are absolutely right about methods. I actually hoped someone would ask, but you found the solution yourself. This is exactly the way it is supposed to work. As for events, you cannot generate them at run-time for ExpandoObject, as far as I know. But I'll check it once again with the DLR team.
Anonymous
October 02, 2009
Hey, this is John from the DLR team. Here's an example of doing events on ExpandoObject: using System; using System.Dynamic; namespace ConsoleApplication2 { class Program { static void Main(string[] args) { dynamic d = new ExpandoObject(); // Initialize the event to null (meaning no handlers) d.MyEvent = null; // Add some handlers d.MyEvent += new EventHandler(OnMyEvent); d.MyEvent += new EventHandler(OnMyEvent2); // Fire the event EventHandler e = d.MyEvent; if (e != null) { e(d, new EventArgs()); } // We could also fire it with... // d.MyEvent(d, new EventArgs()); // ...if we knew for sure that the event is non-null. } static void OnMyEvent(object sender, EventArgs e) { Console.WriteLine("OnMyEvent fired by: {0}", sender); } static void OnMyEvent2(object sender, EventArgs e) { Console.WriteLine("OnMyEvent2 fired by: {0}", sender); } } }
Anonymous
October 02, 2009
I'm not too sure about using ExpandoObject in this case. Wouldn't it cause memory issues when using ExpandoObjects this way in a long running process? Because ExpandoObject caches "classes" and their transitions, it might keep a lot of information that doen't have much use later on in this scenario -- the cache is good when the structure of an "object" doesn't change often, but if it's used like a property bag that changes often, we might be better off falling back to go without caching. I thought inheriting from DynamicObject would do the jot better, since we can make a proprty bag impl backed up by a plain old dictionary, without all the caching.
Anonymous
October 02, 2009
@John: Your solution for events is far simpler than what I was trying to do. I was trying to take advantage of events being a sugar for delegates, and therefore trying to dynamically build a delegate and assigning it to as a member of the dynamic object, and then assigning handlers.
Anonymous
October 02, 2009
Would it be possible to implement property deletion as something like "expando.Property = ExpandoObject.Removed"?
Anonymous
October 02, 2009
Sorry for the double-post, but now that I think of it, I think ExpandoObject.Remove(expando); would be better, or DynamicObject.Remove() if you wanted a consistent method of removing properties from dynamic objects.
Anonymous
October 02, 2009
The value of this feature is negligible, at least as long as Intellisense and strong type-checking is not supported (for now, it's just a dictionary in disguise...). I bet many of us would love to see the C# team focusing and spending its time on fixing issues that truly bother programmers, such as the lack of deterministic destruction (google for "lior eti deterministic destruction" for a good article on missing features that truly bother programmers, as well as a discussion with practical suggestions for implementing deterministic destruction in .NET)
Anonymous
October 03, 2009
Would it be possible to implement property/methods creation using string expression in a [ ] suffix : dynamic contact = new ExpandoObject(); contact["Name"] = "Patrick Hines";?
Anonymous
October 04, 2009
@sagi: Yes, its already there (technically) as long as ExpandoObject has a this[string index] field. IDictionary inherits from ICollection, so IDictionary classes must implement that.
Anonymous
October 04, 2009
The comment has been removed
Anonymous
October 04, 2009
Bravo Alexandra.!Ai articole super tari
Anonymous
October 05, 2009
Interesting use of the dynamic keyword, although I would advise against its usage. It's very hard to catch errors with this sort of coding style and its also a very lazy and sloppy way to code. Typos won't be picked up during compile time because you can just declare anything anywhere.
Anonymous
October 05, 2009
I find this kind of dynamic coding very interesting. I have a coment about the naming, though. Correct me if I am wrong, but I had the impression that the term "expando" was short for saying "expandable object", meaning an object that can be dynamically expanded/extended. That would mean that "ExpandoObject" would actually mean "ExpandableObjectObject", which makes no sense. I think it should be named either just "Expando" or "ExpandableObject"; I think the latter is clearer.
Anonymous
October 05, 2009
Vince: Another concern if you have the potential for sloppy programmers to "infect" a small and seemingly innocuous method in a large & complex back-end. A "fix" to a malfunctioning, if otherwise well-written method could be hastily rewritten with an ExpandoObject by someone with a lack of time or experience, and your typo could cause a property to go unread, passing "reasonably assuming" unit tests in a local class neighbourhood but having a seriously detrimental effect in another part of the system. Tools such as ReSharper would undoubtedly be invaluable, though their use would still be no guarantee of code cleanliness.
Anonymous
October 05, 2009
Simon, If you feel that this method is really necessary for ExpandoObject, you can post your suggestion at https://connect.microsoft.com/VisualStudio However, by "syntax for removing object members" I meant that some dynamic languages have special language keywords for deleting members. Someting like "delete sampleObject.SampleProperty". C# doesn't have such a syntax.
Anonymous
October 05, 2009
This week on Channel 9, Dan and Brian reunite to go through the week's top developer news including: C# FAQ - Using the ExpandoObject with Dynamic C# http://channel9.msdn.com/shows/this+week+on+channel+9/twc9-sql-azure-mvc-2-new-channel-9-content/
Anonymous
October 05, 2009
This is great... As the ExpandoObject is doing this dynamic stuff by implementing the IDictionary interface, so all of the dynamically added properties - and methods as well- will just belong to THIS object. so I wonder if there is any workaround to add these to the declaring type itself, i.e any instance of type ExpandoObject will have this dynamically added method This would be very useful for methods, just like we do in JavaScript using the prototype
Anonymous
October 06, 2009
This must be a grand microsoft joke, really what a waste of my time. Since something is not easily made type safe at compile time we just fake it? lol.
Anonymous
October 06, 2009
Anwer, I think DynamicObject can help you here. This is another class from System.Dynamic namespace. With DynamicObject you can define what actually happens when you call a method or a property of an object. I am planning a blog post about DynamicObject and I hope it will answer a lot of questions asked here.
Anonymous
October 07, 2009
Anwer, I'd be curious if Extentions would help you here: namespace ExpandoObjectExtentions { public static class ExpandoObjectExtentions { public static void MyGlobalExpandoMethod(this ExpandoObject eo, string a) { Console.WriteLine("Called MyGlobalExpandoMethod. {0}",a); } } }

using ExpandoObjectExtentions; dynamic d = new ExpandoObject(); d.MyGlobalExpandoMethod("Hi");

Anonymous
October 08, 2009
Why do you believe this is difficult to read? myObject.GetProperty("Address") I feel that the exapander implementation of the above is deceiving. The exapander may make the code look prettier (more readable), but in terms of maintainability (where readability is imporatant), I woulld perfer the GetProperty route. With GetProperty, developers know by looking at the source code what properties myObject really exposes. This is important so the dev can glance at the code and get a feel for where their breaking points are, and perform bounds/null checking/handling rather than assuming b/c its a prop that it will always exist.
Anonymous
October 08, 2009
Can I use a syntax like: dynamic contact = new ExpandoObject { Name = "Bethoven", Phone = "123-356-7899", Address = new ExpandoObject { Street = "123 Main St", City = "Redmond", State = "WA", ... } }
Anonymous
October 08, 2009
@ Eric It might be not that difficult if you are getting or setting a single property. But in case of hierarchical objects that operate with both numerical and textual data... Or, for example, how about this one? Scriptobj.PropeSetProperty("Count", ((int)GetProperty("Count")) + 1); Isn't this one look much easier to read? scriptobj.Count += 1; @George No, this syntax is used for anonymous types. var contact = new { Name = "Patrick", Address = new { City = "Redmond" } }; The difference is that in this case we actually create a static type, only this type has no name. With ExpandoObject, we in fact don't create any properties. We simply "overload" operations that get and set properties and make them search in a dictionary instead of a static type definition. Both approaches have their own pros and cons.
Anonymous
October 08, 2009
If I ever use code that might look like this: myobject.GetProperty("Address"), it's because I most likely will do something like this: string prop=ds.Tables[table].Rows[0][field].ToString(); string dynamicValue=myobject.GetProperty(prop); I may have some scripting code in my database and it will determine the property to get. This is dynamic.
Anonymous
October 08, 2009
To retake the question of Anwer Matter, there could be some scenari where it may be nice to generate dynamically a type, declaring methods and events, and then creating instances of that "type" (of course these instances would be of type dynamic. Here is an example : dynamic person = new ExpandoObject(); //1. Define properties person.Name = ""; person.FirstName = ""; //2. Define instance methods person.ToString = new Func<string>(() => person.Name + " " + person.FirstName ); //3. Define an event person.MyEvent = null; person.OnMyEvent = new Action<EventArgs>((e) => { if (person.MyEvent != null) person.MyEvent (person, e); }); We may not know the properties to use in some methods until runtime and that would be great to be able to use after instance of this "type person" to create new objects. Or at worse to "clone" this instance to use it after. Is there any way to do that ? Kind regards,
Anonymous
October 09, 2009
Pierre, There are various ways to do things like that. What you are describing sounds like a prototype language. The canonical (and easiest) way to do it would be to have a constructor function: dynamic CreatePerson() { // supply args here if desired dynamic person = new ExpandoObject(); //1. Define properties person.Name = ""; person.FirstName = ""; //2. Define instance methods person.ToString = new Func<string>(() => person.Name + " " + person.FirstName ); //3. Define an event person.MyEvent = null; person.OnMyEvent = new Action<EventArgs>((e) => { if (person.MyEvent != null) person.MyEvent (person, e); }); return person; } You could also make something that cloned an ExpandoObject. It’s a little bit tricky (you have to rebind delegates), but it should be doable.
Anonymous
October 12, 2009
Maybe I'm missing something. I don't see how this makes code easier to Maintain and Understand. This seems like a step backwards. Please be kind in your response, I'm just looking for how this makes the final (developed) product better. Thx
Anonymous
October 13, 2009
Can you still call C# a type-specific language with the introduction of the dynamic type? Wasn't that the whole point, catch your errors at compile time and not run-time? VB has done this very same functionality for years, including type conversion without casting. Is an attempt to bring the two languages closer together?
Anonymous
October 13, 2009
Dynamic in C# is primarily to enable C# programs to interoperate better with API's and object models defined in dynamic languages, without which you would be force to write very difficult to understand code, where the meaning gets lost in the mechanics.
Anonymous
October 14, 2009
it is great I have gone through all this conversation and found it very usefull. thanks
Anonymous
October 15, 2009
I find that since C# 2.0, it's no more a real programing language but a experimental binding language. All new features since 2.0 are the answer to the ORM needs. For me, LINQ and dynamic object should be in "Microsoft ORM framework". Not in C#. C# was pretty clean as a language. Able to compete with c++. Now it become a joke.
Anonymous
October 16, 2009
I agree with the general sentiment of the latter half of respondents. This seems to be a step backwards to late binding days to me. I may be a bit short-sited on this, and may be able to be persuaded of its use in very specific cirumstances, but the need for this level of dynamic coding seems to point to a problem in solution design. I am all for Agility, but this leaves too much room for problems with scalability and capacity planning.
Anonymous
October 16, 2009
I've a post here to examine the ExpandoObject itself is implemented. To make this clear, let us consider a MyExpando class, a minimal implementation of ExpandoObject. I'm inheriting MyExpando class from the DynamicObject, and these are the major methods we are overriding. TrySetMember- Provides the implementation of setting a member. TryGetMember-Provides the implementation of getting a member. TryInvokeMember- Provides the implementation of calling a member. GetDynamicMemberNames- Returns the enumeration of all dynamic member names. http://amazedsaint.blogspot.com/2009/09/systemdynamicexpandoobject-similar.html
Anonymous
October 18, 2009
Wouldnt this be a dangerous thing for security? I can imagine scenarios where someone passes in an expando object in a method that expects certain objects. The syntax will be alright sice its dynamic but I can imagine the whole system crashes at runtime. So isnt this a problem when using remoting for example?
Anonymous
October 20, 2009
Very interesting. This should clean up areas where I'm dealing with REST services (no strong names)
Anonymous
October 21, 2009
The comment has been removed
Anonymous
October 21, 2009
@Mast10 I think you misunderstand the concept a little bit. You actually can't pass ExpandoObject to a method that expects a certain type. Let's consider this example: static void Main(string[] args) { dynamic test = new ExpandoObject(); Sample(test); } static void Sample(IEnumerable<String> arg) { Console.WriteLine("Got there"); } This will compile, but Sample(test); will throw an exception at run time. It will tell you that there is no necessary overload of the Sample() method. Note that you will never get into the Sample method itself. All the problems will be in the code where you create and operate with dynamic objects, but not in some method that expects a certain type of object. The only way to get into Sample method for a dynamic object is to be of the requested type. For example, the following works fine: dynamic test = new List<String>(); Sample(test); It works, because when we call the method, "test" has the requested type. Now, where can you pass ExpandoObject to? Well, in any method that accepts parameters of type "object", "dynamic", or "ExpandoObject". But if method accepts parameters like "object" and "dynamic", it should be ready that it can get anything and act accordingly. I don't think that passing a dynamic object to a method that expects "object" should crash any well-written system, becuase it should be performing all type-checking already.
Anonymous
October 22, 2009
To maintain control over strong typing for frameworks and libraries, team build environments should prohibit "using System.Dynamic". Is anyone here (eg. Stephane) trying to tell me that C++ pointers are any less of a problem when utilized by sloppy developers?!
Anonymous
October 25, 2009
Could be very usefull, especially if you don't like coding much. Very flexible. But still agree with some comments, which say that it can bring a lot of errors.
Anonymous
October 26, 2009
Yup. Seen that for years in Adobe Flex. But it's just called object().
Anonymous
October 27, 2009
Would this work in the current implementation ? contact.Address = new ExpandoObject().Street = "123 Main St";
Anonymous
October 28, 2009
@ D0cNet No, this is not supported. It's important to understand that dynamic feature cannot support syntax that C# language does not support. For example, some languages have syntax like "delete obj.Member", but C# does not have this syntax, and so you simply can't write such a code, no matter whether you use dynamic or statically-typed objects. The same is here: C# does not allow you to call methods on constructors, neither for statically-typed objects, nor for dynamic ones.
Anonymous
November 06, 2009
The comment has been removed
Anonymous
November 11, 2009
Looks great, and I now understand it.. but I am on the fence about it. Thanks for the writeup for sure
Anonymous
November 12, 2009
Adobe's Actionscript language has slowly been moving away from expando objects to strongly typed code (for performance reasons mainly). Why is C# moving in the other direction?! I want strongly typed ECMAScript, not loosely typed C# ;-)
Anonymous
November 13, 2009
I have come o truly love LINQ to Objects, LINQ to XML, and other goodies from C#3.0 like implicit [static] typing, and anonymous types (which are still static but inherently more less restricted to a small, immediate scope limiting risk). Having started to get a little deeper into Javascript I'm finally 'getting' the dynamic/prototyping paradigm, but I fear mixing it in with C# will be a real can of worms. Perhaps it would be best to simply create a .NET assembly using one of the other languages more natively intended for this, and use it from your C# assemblies rather than possibly ruining C# by trying to throw in everything but the kitchen sink.
Anonymous
November 20, 2009
What I always disliked about the myobject.GetProperty("Address") solution was that you don't have any Intellisense-support and often have to look up the properties names (typing errors included). Is there any chance that there will be Intellisense-support for this in the future?
Anonymous
November 23, 2009
@ Matthias I am not aware of such a feature right now. I usually advise people to file their suggestions about new features at http://connect.microsoft.com/.
Anonymous
November 23, 2009
Someone can shoot himself in the hand with a nailgun, but that doesn't mean it isn't worthwhile technology, and superior to a hammer for certain applications. I appreciate the C# team assuming it's customers are, by and large, responsible professionals. No nanny state, please.
Anonymous
November 25, 2009
why would anyone need to have methods added at run time? why not just add them to the class definition when programming it, you know that something might be needed before compiling, so may as well do it the simpler way.
Anonymous
November 25, 2009
The comment has been removed
Anonymous
December 17, 2009
Hohoho, people, have You ever heard about PHP ? This kind of construction is pretty old there. Sample: <?php $obj = null; $obj->Val_a = 1; $obj->Val_b = 'test'; echo $obj->Val_b,'#',$obj->Val_a; // output is test#1 ?>
Anonymous
December 19, 2009
Can you serialize and deserialize dynamic objects?
Anonymous
February 01, 2010
Really looking forward to all this 2010/4.0 stuff.
Anonymous
February 11, 2010
I just like the name - 'ExpandoObject' - brilliant!
Anonymous
March 30, 2010
For those sniping at how 'real programmers' wouldn't use this, consider that expando objects and properties are widely used in Javascript and that the IE DOM supports them against any HTML element. This sort of functionality makes it much easier to interoperate with dynamic languages etc, and it also makes it easier to add functionality to an application such as an internal macro language for automation etc. It's just another tool, after all. Remember that Pascal was designed on the 'mummy knows best' principle and was rightly criticised for its limitations, enforced supposedly to ensure 'good programming practices'. Frankly, if I want to use a hammer to open a can of tuna, that's my prerogative, thank you very much.
Anonymous
April 27, 2010
The comment has been removed
Anonymous
May 04, 2010
I find the fact that the object type 'dynamic' does not support dynamic operations. I am refering to the following statement from the above article," (Once again, references to the ExpandoObject objects are statically-typed and do not support dynamic operations.) " 99% of everything I program is dynamically directed through user input or selection. All of my programming is web based and I do not deal with office apps so maybe there is where one would need a non-dynamic method of data manipulation. Can you give a quick explanation on why someone would give the name 'dynamic' to an object that does not support dynamic operations? Thanks, John P.
Anonymous
May 11, 2010
In your example: dynamic contacts = new List<dynamic>(); contacts.Add(new ExpandoObject()); contacts[0].Name = "Patrick Hines"; contacts[0].Phone = "206-555-0144"; contacts.Add(new ExpandoObject()); contacts[1].Name = "Ellen Adams"; contacts[1].Phone = "206-555-0155"; To create a "Location" with attributes you need to go: contacts[0].Location = new ExpandoObject(); contacts[0].Location.Street = "StreetName1"; and contacts[1].Location = new ExpandoObject(); contacts[1].Location.Street = "StreetName2"; Since intellisense and compilation errors are ignored regardless, why do you even need the: contacts[0].Location = new ExpandoObject(); ? You could just go contacts[0].Location_Street = "StreetName1"; Or the . values after Location should be dynamically created like the values of "Location" itself (EG: Streetname) Hope I made any sense ;p

Reelix

Anonymous
June 08, 2010
I've an ElasticObject implementation, that'll allow you to go with multiple levels of properites.. aka. dynamic obj=new ElasticObject(); obj.Customer.Name.FirstName="Joe"; obj.Customer.Age="30"; And you can convert that directly to xml - amazedsaint.blogspot.com/.../introducing-elasticobject-for-net-40.html
Anonymous
August 25, 2011
The comment has been removed
Anonymous
October 16, 2011
The comment has been removed
Anonymous
January 16, 2012
hello.. I am trying to dynamically create an XML file. I came across the ExpandoObject which seems to suit my goals. But when I have the List <dynamic>, i cannot do the expandoToXML conversion, in the procedure suggested above. I. e. [CODE] //--------------------------------------- dynamic myXML = new List<dynamic>(); private static XElement expandoToXML(dynamic node, String nodeName) { XElement xmlNode = new XElement(nodeName); foreach (var property in (IDictionary<String, Object>)node) { if (property.Value.GetType() == typeof(ExpandoObject)) xmlNode.Add(expandoToXML(property.Value, property.Key)); else if (property.Value.GetType() == typeof(List<dynamic>)) foreach (var element in (ExpandoObject)property.Value) xmlNode.Add(expandoToXML(element, property.Key)); else xmlNode.Add(new XElement(property.Key, property.Value)); } return xmlNode; } //--------------------------------------- [/CODE] Though the code above seems to work, but not with the List. I try this: [CODE] for (int i=0; i<6; i++) { myXML.Add(new ExpandoObject()); ImyXML[i].testProperty=Convert.ToString(i); } //--- conversion XElement temp = expandoToXML(myXML, "testing"); [/CODE] I get the follwing error: Cannot vonvert type "System.Collection.Generic.List´1[System.Object] to type "System.Collection.Generic.Idictionary´2[System.String,System.Object]" ... any ideas? has anybody tried this?an error in my code?
Anonymous
January 20, 2012
To whomever is having trouble with "dynamic myXML = new List<dynamic>(); to XML", have a look at this example, it does exactly what your having trouble with. The author references and gives credit to this article: www.codeproject.com/.../dynamicincsharp.aspx
Anonymous
October 18, 2013
For those that can't find any practical use for Expando, i have something. They could use them as results in various linq to entity queries, when those are used just for display/reporting. The would remove the nessesity to create viewmodels for each view, or having to query for the entire entity for use in a plethora of screens.It's support for binding and with use of serialization could help a lot when there are sources with generic output. Regards.
Anonymous
March 21, 2014
As an aside it might be cleaner to read the code and use the is instead of comparing types: if (property.Value is ExpandoObject )

Condividi tramite

Dynamic in C# 4.0: Introducing the ExpandoObject

Comments

Risorse aggiuntive