What is the point of having a dynamic class on which you can call methods that may, or may not be there?
-
The point is that you'll usually be confident that the method will be present (or handled dynamically - e.g. a
FindByAuthormethod in a "book repository" class which is translated into an appropriate SQL query) but that you don't know the static type - or where the interfaces are fairly weakly typed (e.g. the Office COM APIs).I wouldn't expect dynamic typing to be useful very often in C# - but when it's handy, I suspect it'll be very, very handy.
-
Primarily it allows C# 4 to interop much better with objects provided by the DLR using languages like Python. It also allows much easier interop with typical COM objects without the need to create interop assemblies.
-
One reason is make it easier to use interop with COM using late-binding. So you do not have to use the interop assemblies anymore.
This is very nice if you need to call different version of the COM server. For example when you need you application to work with different versions of Office.
-
I would certainly not use it ouside interop scenarios. In dealing with assemblies or code written in dynamic languages, it simplifies the design time experience. In these cases you have to make the assumptions about the dynamic types anyway. You will get your exception at run time if your assumptions are failing either way.
Think of it as a shorthand for Invoke or reflection.
-
Another issue could be in writing a code that should work with some range of assembly versions. Say a plug-in where no assembly bindings are defined. And now one will need to compile same source code for a number of host assembly versions.
In that case feature like 'duck typing' would be a good solution.
0 comments:
Post a Comment