“I want static behavior between assemblies/libraries/packages but dynamic abilities within.” – JeffreyPalermo.com

With C# 4.0, code within method can be dynamic because of the new dynamic keyword.  This is a short post expressing what I want out of C#.

I recently listened to a great debate about the advantages and shortcomings of both dynamic and static languages, and the biggest pain of 100% dynamic languages is that when using a library, you really don’t know what is supports except if the documentation is liberal and flawless.  There are no interface types to describe what properties and methods will be called once you pass the object in.  If the documentation doesn’t cover every API, you are forced to write characterization tests.

The other big challenge is that when working with a dynamic language, you have to keep more of the system in your head in order to program.  You have to remember which object is overriding which method, and what objects have new functionality attached to them.

Both of these points are only an issue between package boundaries.  Within a package, everything is fine because you own all that code.  All the conventions are yours.  This dovetails with the main strength of a static language:  All the APIs are self-describing.  Every method declares types on the arguments.  Objects explicitly implement interfaces.

The problem with static languages is that this rigor is extended within the package as well forcing the programmer to write every method body using the same compiler strictness of typing.

If we can have a dynamic keyword in C# so that code within a method body is dynamic, then some of this might already be achieved.  We’ll have to see.  Public interfaces that are at package boundaries need to be self-describing, from my point of view.  After that, writing dynamic code within controlled boundaries can make things go smoother.