Please reconsider the dynamic keyword! - by Daniel Earwicker

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
2
Sign in
to vote
ID 417826 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 2/25/2009 2:16:30 AM
Access Restriction Public

Description

I suggest that the dynamic keyword is a feature that would be better implemented by a single extension method, i.e. a library solution. The result would avoid the major problems with dynamic while losing none of its capabilities.
Sign in to post a comment.
Posted by Daniel Earwicker on 3/18/2009 at 3:45 AM
I figured that would be the answer, especially at this late stage - I think all of those are great points, except for:

1. the part about operators - it's a common request for it to be made possible to capture such things in interfaces, especially for development with generics so they can be specified as constraints, and it's odd that now we can do so only by giving up type safety altogether.

2. the part about a static interface wrapper giving false guarantees. Any use of dynamic calls means that implicit, unchecked assumptions are made by the caller. By gathering those assumptions in one place, it doesn't make it any more misleading than it already would be - either way, we have unchecked calls. The advantages of stating these assumptions in one place are: intellisense, hence greater ease of use, and easy of maintenance when it's time to update those assumptions. We would basically have a single definition saying "These are my assumptions about what dynamic calls I expect to be available".

Since posting this I've realised something that should have been obvious to me before - I can implement my suggestion as a library and 'dynamic' makes that easy to do via code generation. So as you say, I don't need dynamic to be removed - I just need to do a little work to enable what I wanted.

Thanks for the reponse.

--Daniel
Posted by Microsoft on 3/4/2009 at 10:46 AM
Hi Daniel,

Thanks for your proposal!

We are in fact very happy with our current design of dynamic, for several reasons:

- We really do want to embrace as first-class the truly dynamic nature of several kinds of objects on our platform - including those coming from dynamic languages such as Python, Ruby and JScript.
- Compiler involvement is needed at the call site to make the dynamic dispatch efficient
- not all operations can be captured by an interface, in particular operators and (hence) conversions
- most dynamic operations are only invoked one or a few places in a C# program; needing to maintain an interface for that is painful and wasteful
- for the remaining cases you might want to occasionally wrap a dynamic object in an interface or other strong type: That is very easy to do
- having a static interface wrapper for things that are truly resolved dynamically in fact makes it less clear to the user that binding is deferred to runtime - in essence giving false guarantees.
- if you really distrust dynamic and don't want to use it you can switch it off by removing the reference to the C# runtime

You may not agree with all of these points, but at least you can see that we have strong reasons for wanting our current design. It is not for lack of awareness of other approaches that we chose it - we simply felt that it was the best.

Thanks again,

Mads Torgersen, C# Language PM