14

I have been recently studying more on the dynamic types in C#. With some examples I understood once the code is compiled, it does not need to be recompiled again but can be executed directly.

I feel the flexibility provided by the keyword to actually be able to change data type at will is a great advantage.

Question,

Are there any specific shortcomings apart from wrong dynamic method calls which throw run time exceptions which developers must know before starting the implementation.

| improve this question | |
  • 3
    In C# 3, I always considered the use of object or direct type casts to be a code-smell. In almost every case it meant that I or one of my team hadn't designed an appropriate interface for that functionality. I'm guessing that if I were using C# 4 now, I would feel pretty much the same way about use of dynamic too. I could see the case for it if you make everything dynamic, but in that case you might as well have selected a dynamic typed language in the first place. *8') – Mark Booth Feb 15 '12 at 11:47
  • @MarkBooth +1 for the perspective. Is it then safe to say that the core implementation using C# is still going to remain strongly typed in-spite of introducing dynamic types in 4.0 – Karthik Sreenivasan Feb 15 '12 at 11:56
  • Using dynamic in C# means you don't have to drop out to IronPython if all you need is some dynamic typing for a small part of your code. For an expression evaluator, I've had great success using dynamic to represent the operands of an expression and the results from evaluation. – Ed James Feb 15 '12 at 15:41
  • @EdJames - That sounds like a great use of dynamic, plus I wish I'd known about IronPython when I was developing with .Net - it could have made certain things we were trying to do much easier. – Mark Booth Feb 21 '12 at 14:40
  • See stackoverflow.com/questions/31859016/… – nothingisnecessary Nov 23 '16 at 20:08
17

The main shortcoming is that you throw away one of the main properties (not necessarily advantages) of C# - that it is statically typed (and for most part type safe).

The problem with dynamic typing is that it often hides bugs that would be otherwise revealed during compilation. Such bug then only manifests on run-time, which of course makes it much harder to detect.

There are IMO very few reasons to use dynamic typing in C#, the main one being collaboration with dynamically typed languages (which is AFAIK the reason dynamic was introduced in the first place).

If you want to do fully dynamically typed programming, you should look at some language which is designed to be dynamic, not hack C# to be dynamic. You can use for example IronPython if you want to use .Net libraries

| improve this answer | |
  • +1 for IronPython. This means that this could lead to maintenance issues in the long run. – Karthik Sreenivasan Feb 15 '12 at 10:53
  • 6
    The big thing that dynamic gives you is the ability to up-cast an object to its actual type without any kind of reflection hack. For example if Base foo = new Derived(); and there were two overloaded methods Moo(Base x) and Moo(Derived x), then Moo(foo) calls Moo(Base x), but Moo((dynamic)foo) calls Moo(Derived x). This leads to a very elegant implementation of the Visitor pattern for example: code.logos.com/blog/2010/03/… and is in general a very powerful technique. – user23157 Feb 15 '12 at 12:56
  • @TheMouthofaCow Nice, there surely are a few other "legitimate" uses for dynamic as well, however these are few and far in between (and you definitely have to know what you are doing before attempting something like this). – Matěj Zábský Feb 15 '12 at 13:14
  • @TheMouthofaCow A relatively new design pattern ( The Visitor Pattern ) to note. Thanks. – Karthik Sreenivasan Feb 15 '12 at 13:34
  • 1
    Yes, it's pretty cool. I came up with it independently last week, so it was nice to see that it is an accepted idea that's been adopted into the C# arsenal. – user23157 Feb 15 '12 at 15:05
10

I'm not sure what kind of shortcomings are you looking for, but if you want to know about features that work with static typing, but not with dynamic, there are few:

  1. Extensions methods don't work. This is probably the biggest one. If you have dynamic collection, you can't use code like collection.Distinct(). That's because available extension methods depend on namespace usings and the DLR has no way of knowing them.

    As a workaround, you can either invoke the method as if it was normal static method: Enumerable.Distinct(collection). Or you can change the type of the collection to something like IEnumerable<dynamic>.

  2. foreach requires IEnumerable. In normal C#, foreach is pattern-based. That is, it doesn't require any specific interface, just a GetEnumerator() method that returns suitable object. If you use foreach on dynamic, the implementation of IEnumerable is required. But since the reason for this behavior is that C# 1.0 didn't have generics, this "shortcoming" is pretty much irrelevant.

| improve this answer | |
  • +1 for extensions method. Does this also apply to other LINQ query operators like GroupBy() ? – Karthik Sreenivasan Feb 15 '12 at 12:34
  • 2
    @Karthik: Yes it does. I think extension methods are compile time syntactic sugar, hence the fact that they don't get resolved. – user23157 Feb 15 '12 at 12:46
  • @TheMouthofaCow +1 - Thanks for the clarification. – Karthik Sreenivasan Feb 15 '12 at 12:48
  • 1
    I agree with the extension methods, i.e how the dynamic cannot figure out extension methods at run time but I could not follow the dynamic collection you have explained. – Karthik Sreenivasan Feb 24 '12 at 7:13
8

The problem with dynamic types (not variables declared as dynamic) in .net is that they don't have a lot of the functionality available to static types.

  • there's no reflection (you can iterate over members but not much else)
  • no metadata (there goes your validation in dynamic data sites/mvc)
  • absolutely no checking at compile time (any misspellings will not be caught)
  • since this is a powerful feature noobs may tend to abuse/misuse/misunderstand it
  • code written with dynamic types tends to be hard to maintain and damn hard to refactor
  • because of duck typing and other features gurus may write code that is unreadable to anyone else

So don't write code with dynamic types unless you know what you are doing.

| improve this answer | |
6

Since dynamic is just a marked object it boxes value types.

This can have performance implications, but since I'd use static typing in performance critical code anyways, that's probably not a problem in practice.

This boxing also interferes with mutable value types. If you modify them with dynamic, you only modify the boxed copy. But since you should not use mutable value types in the first place, this isn't a big problem either.

| improve this answer | |
  • +1 I definitely agree. Static typing would be the best approach for performance critical code. – Karthik Sreenivasan Feb 16 '12 at 2:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.