Click here to Skip to main content
15,892,161 members
Articles / Programming Languages / C#

C# Proposal: Compile Time Static Checking Of Dynamic Objects

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
15 Apr 2010CPOL2 min read 26.8K   1   16
C# Proposal: Compile Time Static Checking Of Dynamic Objects
free hit counters

C# 4.0 introduces a new type: dynamic. dynamic is a static type that bypasses static type checking.

This new type comes in very handy to work with:

Because static type checking is bypassed, this:

C#
dynamic dynamicValue = GetValue();
dynamicValue.Method();

is equivalent to this:

C#
object objectValue = GetValue();
objectValue
    .GetType()
        .InvokeMember(
            "Method",
            BindingFlags.InvokeMethod,
            null,
            objectValue,
            null);

Apart from caching the call site behind the scenes and some dynamic resolution, dynamic only looks better. Any typing error will only be caught at run time.

In fact, if I'm writing the code, I know the contract of what I'm calling. Wouldn't it be nice to have the compiler do some static type checking on the interactions with these dynamic objects?

Imagine that the dynamic object that I'm retrieving from the GetValue method, besides the parameterless method Method also has a string read-only Property property. This means that, from the point of view of the code I'm writing, the contract that the dynamic object returned by GetValue implements is:

C#
string Property { get; }
void Method();

Since it’s a well defined contract, I could write an interface to represent it:

C#
interface IValue
{
    string Property { get; }
    void Method();
}

If dynamic allowed to specify the contract in the form of dynamic(contract), I could write this:

C#
dynamic(IValue) dynamicValue = GetValue();
dynamicValue.Method();

This doesn't mean that the value returned by GetValue has to implement the IValue interface. It just enables the compiler to verify that dynamicValue.Method() is a valid use of dynamicValue and dynamicValue.OtherMethod() isn't.

If the IValue interface already existed for any other reason, this would be fine. But having a type added to an assembly just for compile time usage doesn't seem right. So, dynamic could be another type construct. Something like this:

C#
dynamic DValue
{
    string Property { get; }
    void Method();
}

The code could now be written like this:

C#
DValue dynamicValue = GetValue();
dynamicValue.Method();

The compiler would never generate any IL or metadata for this new type construct. It would only be used, at compile time, for static checking of dynamic objects. As a consequence, it makes no sense to have public accessibility, so it would not be allowed.

Once again, if the IValue interface (or any other type definition) already exists, it can be used in the dynamic type definition:

C#
dynamic DValue : IValue, IEnumerable, SomeClass
{
    string Property { get; }
    void Method();
}

Another added benefit would be IntelliSense.

I've been getting mixed reactions to this proposal. What do you think? Would this be useful?

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior) Paulo Morgado
Portugal Portugal

Comments and Discussions

 
GeneralGo Pin
Qwertie21-Apr-10 4:59
Qwertie21-Apr-10 4:59 
GeneralRe: Go Pin
Paulo Morgado23-Apr-10 2:12
professionalPaulo Morgado23-Apr-10 2:12 
GeneralRe: Go Pin
Qwertie23-Apr-10 4:24
Qwertie23-Apr-10 4:24 
GeneralRe: Go Pin
Paulo Morgado23-Apr-10 8:09
professionalPaulo Morgado23-Apr-10 8:09 
GeneralRe: Go Pin
Qwertie23-Apr-10 16:07
Qwertie23-Apr-10 16:07 
GeneralRe: Go Pin
Paulo Morgado25-Apr-10 11:56
professionalPaulo Morgado25-Apr-10 11:56 
GeneralRe: Go Pin
Qwertie28-Apr-10 18:10
Qwertie28-Apr-10 18:10 
GeneralRe: Go Pin
Paulo Morgado28-Apr-10 21:53
professionalPaulo Morgado28-Apr-10 21:53 
GeneralWish-list item: narrowly-scoped extension types/functions Pin
supercat915-Apr-10 5:38
supercat915-Apr-10 5:38 
GeneralRe: Wish-list item: narrowly-scoped extension types/functions Pin
Paulo Morgado15-Apr-10 12:47
professionalPaulo Morgado15-Apr-10 12:47 
GeneralRe: Wish-list item: narrowly-scoped extension types/functions Pin
supercat916-Apr-10 6:08
supercat916-Apr-10 6:08 
Paulo Morgado wrote:
Can you provide code samples for what you are proposing as extension types?


In VB-style, something like:
Extension xStringBuilder
  Extends System.Text.StringBuilder

  Public Property Value() As String
    Get
      Return Me.ToString
    End Get
    Set(ByVal Value as String)
      Me.Length = 0
      Me.Append(Value)
    End Set
  End Property

  Public Sub Clear
    Me.Length=0
  End Sub
End Extension

Extension xDisposable
  Extends iDisposable

  Public Shared Sub Dispose(ByVal Shared Self As xDisposable)
    ' Note the following cast will always be valid, and the compiler
    ' will know this; no need for a run-time check.
    If Self isNot Nothing then Ctype(Self,iDisposable).Dispose
  End Sub
End Extension

Extension xZap(of T)
  Extends T

  Public Shared Sub Dispose(ByVal Shared Self as xZap(of T))
    If Self IsNot Nothing Then
      Dim Thing As iDisposable = TryCast(Self, iDisposable)
      If Thing IsNot Nothing Then Thing.Dispose
    End Thing
  End Sub
End Extension

A program could use xStringBuilder anyplace it would otherwise use System.Text.StringBuilder, xDisposable anyplace it would use iDisposable, and xZap(of someType) anyplace it would use someType. Any time the types were referred to as xStringBuilder, xDisposable, or xZap, the extension methods would be used. Otherwise they would not be.
Paulo Morgado wrote:
As for your Zap method, although valid for the compiler, it is not recommended to use extension methods on null instances because the same method might be added on a future version of the extended type and it might break recompiled code.

With the existing extension-method semantics, if a type that's extended is changed there's a danger of breaking existing code whether or not one uses null instances. For example, if one extended Graphics with a DrawParallelogram function that took three vertices and drew a parallelogram whose unspecified vertex was opposite the first, and such a function was later added to the Graphics type but the unspecified vertex was opposite the second, code that expected the former behavior would break. If the class were extended via my proposed syntax, the code would not break (since the extension method would always shadow the base-class method for objects declared to be of the extension type).
GeneralRe: Wish-list item: narrowly-scoped extension types/functions Pin
Paulo Morgado16-Apr-10 14:40
professionalPaulo Morgado16-Apr-10 14:40 
GeneralRe: Wish-list item: narrowly-scoped extension types/functions Pin
supercat917-Apr-10 6:23
supercat917-Apr-10 6:23 
GeneralRe: Wish-list item: narrowly-scoped extension types/functions Pin
Paulo Morgado17-Apr-10 10:45
professionalPaulo Morgado17-Apr-10 10:45 
GeneralRe: Wish-list item: narrowly-scoped extension types/functions Pin
supercat919-Apr-10 5:10
supercat919-Apr-10 5:10 
GeneralRe: Wish-list item: narrowly-scoped extension types/functions Pin
Paulo Morgado19-Apr-10 13:04
professionalPaulo Morgado19-Apr-10 13:04 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.