Unfortunately, I was not able to attend the PDC 2008.  But I have read some blog posts from some who attended yesterday.  It looks like C# 4.0 will support many dynamic typing concepts including co- and contra-variance, and although "duck typing" was not explicitly mentioned, it seems to be implied by what I read.  (Since duck typing is a principle of dynamic typing and not necessarily a feature in its own right, I am not surprised it is not named specifically.)

Now don't get me wrong, it was fun writing the duck typing library, but I would have no problem whatsoever if it were made obsolete by this.  Having the features integrated into C# would be awesome, and I'm sure it would eliminate the initial overhead caused by the dynamic compilation used by the duck typing library.

I think I will have to actually use C# 4.0 before I know how it will affect the usefulness of the duck typing library, but I am thinking right now that it may still be useful for interacting with "vintage" code libraries.  That, as I understand it, is actually what Jordan uses the library for most.  So whether C# 4.0 will fit the bill in this respect hinges on whether the dynamic typing features can be used when interacting with libraries that were not written or compiled in C# 4.0.

Unfortunately, I haven't had the chance to spend a lot of time working on the new duck typing library, which may actually have equaled wasted effort, but if such a library would still be useful with C# 4.0, I think it will change significantly from what I originally thought.  It will probably be designed specifically to complement C# 4.0 features.

It has been quite some time since the last release...  (10 months to be precise...)  But a good friend of mine is now onboard and we're resuming development.  We have some pretty cool changes in store, and as always, suggestions are welcome.

We will be tying some loose ends for version 1.0 and rolling in some new features like "loose" duck casting where casting will always succeed, it will simply throw an exception if a member is called that is not implemented, which will more closely resemble how duck typing is implemented in most dynamic languages.  Then we'll be working on 2.0 which will include a name change to something along the lines of "dynamic typing" instead of "duck typing" to reflect the implementation of more dynamic typing concepts than just duck typing.  2.0 will also add some .NET 3.5 features like extension methods.

But I've only scratched the surface...  Just thought I'd give everybody an update!

Binaries: DuckTyping_0.9.30.zip (125.01 kb)
Source: DuckTyping_0.9.30_Source.zip (36.86 kb)

The static page explaining the duck typing project can be found here.

• Fixed: A stack overflow no longer occurs when a duck casting conversion infers the same duck casting conversion.
• Added: Some support for generic methods, but do not expect it to be bug-free.  I had to release it in this state so that the above bug fix would be released.  It should not affect other kinds of class members, though.

Sorry, but comments still don't work...  I'm working on it...

I have become aware that comments are not working on this site.  I was hoping to fix this quickly, but unfortunately, it may involve switching hosting providers.  In any case, I will post as soon as this is working.  Sorry for the inconvenience.

Though I haven't posted in a while since I've been busy, I am still working on the duck typing project.  I have at least one bug fix and I'm working on support for generic methods.  You can expect another release soon.  So stay tuned...

Phil Haack recently posted a blog entry on duck typing.  Read it here.  It gives a very good explanation of it and some of its advantages.

He also gives a very good example of a use for duck typing using my library.  His example demonstrates a feature that I like to call variance in class members.  Specifically, when duck casting an object to an interface, the object need not even implement the interface exactly.  Rather, its members may differ from those defined in the interface as long as the parameter types, return types, property types, and event delegate types are convertible to one another, which may be so via duck typing, as in his example.  Here is an excerpt from his example: (comments mine)

public interface IHttpContext
{
    // Note that the Request property returns IHttpRequest.
    IHttpRequest Request { get;}
}

public interface IHttpRequest
{
    Uri Url { get;}
}
 

In his example, the sealed class HttpContext is duck casted to IHttpContext.  Here is what some of the code might look like for this class for the sake of demonstration:

public sealed class HttpContext
{
    // Here, however, Request returns HttpRequest.  Duck typing still works because HttpRequest
    // can be duck casted to IHttpRequest, which is actually done behind the scenes when Request
    // is called on the duck casted object through the IHttpContext interface.        
    public HttpRequest Request { get { ... } }
    
    ...
}

Scott Hanselman recently posted a blog entry linking here.  Thanks Scott!

He mentioned an interesting question about how this duck typing library fits in with the new C# "var" style declarations and the new dynamic language support of .NET.  I thought I might briefly give my take on this.

"Var" style declarations have a similar but different purpose than duck typing.  When you declare a "var" variable, you are basically saying to the compiler, "You figure out what type it is."  The type is inferred at compile time based on the value that it is assigned.  Then, the variable can be used as if it were that type.  It basically amounts to syntactic sugar.  Duck typing is quite different.  When you cast an object using duck typing, you are instead saying, "It doesn't matter what type this object is, as long as I can interact with it in this way."  It has the advantage of decoupling from the actual type of the object.  This doesn't even have to be known at compile time. 

The original problem that prompted my investigation into duck typing is the problem of versioning in a plug-in system.  Say plug-in A was compiled to be used by version 1.0 of a program.  The program is then updated to version 1.1 and plug-in B is compiled for use with this version.  What about plug-in A?  When its reference to the program library is resolved, version 1.0 will be loaded, whereas the program will load version 1.1.  According to the .NET runtime, these are entirely different assemblies.  Plug-in A implements an interface from version 1.0 and thus cannot be casted to an interface from version 1.1, even if these interfaces are identical.  With duck typing, however, it doesn't matter what interface a plug-in implements, if any.  It can be casted to the current version of an interface as long as it implements all its members.  So problem solved.  Both plug-in A and plug-in B can be interacted with in the same way without having to update plug-in A.

This is similar to dynamic typing in other languages in that certain behavior is performed on an object without knowing it's type, and as long as that object supports that behavior, the code succeeds.  An advantage of duck typing, however, is that it must be known that the object's type implements all of the needed functionality at the time the object is casted.  It does not wait until the functionality is actually used.  Although this does not mean that more problems will be found at compile time, it does mean that problems will surface sooner when the program is executed, even if the code that uses certain functionality is never executed.

Binaries: DuckTyping_0.9.27.zip (123.65 kb)
Source: DuckTyping_0.9.27_Source.zip (33.94 kb)

The static page explaining the duck typing project can be found here.

For those of you who downloaded version 0.9.24 from the old site, there are a few minor updates:

• Fixed: Class member variance by duck typing an interface to another interface now works properly.
• Fixed: Now when duck casting an object to an interface that inherits another interface, the members of the later interface are also implemented (recursive).
• Added: Already, when multiple methods are found that match an interface method, the "best match" is chosen; however, now the return type is taken into account for the sake of explicitly implemented interface methods that may differ only by return type.  (Example, the GetEnumerator() methods of System.Collections.Generic.IEnumerable<T> and System.Collections.IEnumerable)

Feel free to leave general comments on this post about the duck typing library.