C# "dynamic," Part III

re: C# "dynamic," Part III

Steve Cooper — Thu, 30 Oct 2008 19:37:33 GMT

Being a static-loving guy at heart, I'd like to 'tame' dynamic variables as quickly as possible. Will there be a mechanism for something like static duck-typing? So I imagine code like;

interface IDuck { void Quack(); void Waddle(); }

IDuck GetMeADuck()

{

// get a dynamic variable

dynamic couldBeADuck = GetDynamicDuck();

// cast to the IDuck interface, or fail if

// it doesn't implement the methods on the interface

IDuck duck = ouldBeADuck.DynamicCast<IDuck>();

// It Quacks! It Waddles! it's a duck!

return duck;

}

This would be particularly useful in scenarios where a COM API has lots of classes inheriting from an unknown base class. For example, if the API exposes these classes in the interop;

interface Bird { void Eat(); void Move(); }

interface Fish { void Eat(); void Move(); }

interface Duck { void Eat(); void Move(); }

I'd really like to just define an `IAnimal` interface and assign all three types.

re: C# "dynamic," Part III

Anonymous — Thu, 30 Oct 2008 21:41:06 GMT

Wouldn't that just be the same as using Object currently?

re: C# "dynamic," Part III

Steve Cooper — Fri, 31 Oct 2008 10:06:13 GMT

"Wouldn't that just be the same as using Object currently?"

A normal cast only succeeds if the object has been designed to use the type you're casting to. So generally, casting an object to IAnimal interface will fail, _even if the object happens to have Quack() and Waddle() methods_.

My thought is that, with dynamic variables, you could have code that did something like this;

if (dynamicVar.HasMethod(IDuck.Quack) && dynamicVar.HasMethod(IDuck.Waddle))

{

// seems to be a duck

return new CleverWrapper<IDuck>(dynamicVar);

}

else

{

throw new InvalidCastException("This is no duck!");

}

re: C# "dynamic," Part III

David Nelson — Fri, 31 Oct 2008 18:41:15 GMT

I agree with Steve. This kind of capability is the only way that I can see dynamic capabilities having a real use in a statically typed language such as C#. Unfortunately, in many dynamic languages, objects can have members added and removed at runtime, so querying an object for its members at a specific point in time would be a significant limitation. But without that limitation, dynamic typing as it is being presented here is completely misplaced in a stongly, statically typed language such as C#.

re: C# "dynamic," Part III

Balls McTavish — Fri, 31 Oct 2008 21:18:51 GMT

As it just so happens, I also really like cheese. I feel personally that, on a scale from one to ten, it is fantastic! I will be voting for cheese this presidential election...

re: C# "dynamic," Part III

Steve Cooper — Mon, 03 Nov 2008 13:40:34 GMT

@David Nelson

"Unfortunately, in many dynamic languages, objects can have members added and removed at runtime, so querying an object for its members at a specific point in time would be a significant limitation"

You're right -- there is a sense in which this kind of casting is _pretending_ to be static typing. However, there's a class of problems where this is a reasonable thing to do.

As an example, I'm considering embedding python scripts inside a C# application. Each python item would become a class with a small number of methods; say, `Configure()` and `Execute()`.

What I'd like to be able to do is parse a python script to create a dynamic class with these two methods, then cast them to a `IScript` interface. Because this object is basically stable, the cast is reasonable to do. It's not guaranteed, of course, but it's a good start.

re: C# "dynamic," Part III

Daniel Earwicker — Mon, 03 Nov 2008 13:59:30 GMT

I think the dynamic feature is way over the top for the value it provides. As I show here, it is in fact largely possible to implement a terse syntax for making dynamic calls in the current C# language:

http://incrediblejourneysintotheknown.blogspot.com/2008/05/dynamicobject-wrapper.html

The difference due to the new built-in feature seems incredibly tiny to me. It mainly consists of totally disguising the dynamic nature of the calls, which I don't see as a plus.

Community Convergence XLVII

Charlie Calvert's Community Blog — Tue, 04 Nov 2008 00:11:47 GMT

Welcome to the 47th Community Convergence. We had a very successful trip to PDC this year. In this post

re: C# "dynamic," Part III

Artazor — Tue, 04 Nov 2008 12:18:54 GMT

It would be a nice transition between dynamic and static programming - if we could write an external explicit implementations of interfaces (something like adapters) that is to separate the implementation of interfaces from the class definition itself. For example:

class CrazyDuck {

public void LoudQuack() {...}

protected void ShutUp() {...}

}

interface IDuck {

void Quack();

}

implementation CrazyDuck:IDuck {

void Quack() {

try {

LoudQuack();

} cathc(TooLoudException ex) {

ShutUp(); // yes, here we should be able to use it!

DuckHelper.PerformDefaultQuack();

}

After such implementation CrazyDuck class instances should become assignable to IDuck variables. Also I'd propose such a keyword as "interfaceof" that should extract the interface (all public methods, events and properties) of given class. For example:

class Tiger: interface of Cat {

...

}

or even

implementation Tiger: interfaceof Cat {

...

}

this would eliminate a need in corresponing type of refactoring. Also it can be useful to use some constructions for functionality delegation to subitems (like in VB)

It seems to me that this kind of typing would be more consistent than ordinary duck typing.

re: C# "dynamic," Part III

Steve Cooper — Tue, 04 Nov 2008 19:12:29 GMT

@Daniel Earwicker

"it is in fact largely possible to implement a terse syntax for making dynamic calls in the current C# language"

The example you give makes runtime calls to statically-typed object. It isn't a call to a dynamic object.

re: C# "dynamic," Part III

Vijay Santhanam — Tue, 04 Nov 2008 19:56:28 GMT

Yes! Add Duck typing into the framework for dynamic types.

C# "dynamic," Part IV

Chris Burrows' Blog — Thu, 06 Nov 2008 20:45:29 GMT

Today, let's geek out about the language design regarding the dynamic type. Type in the language vs.

re: C# "dynamic," Part III

cburrows — Thu, 06 Nov 2008 21:01:43 GMT

There is no addition to the language that will give you a conversion from some dynamic object to an interface type that it does not actually implement, although you could implement them yourself as Artazor has done. In fact, if you view dynamic as an interop feature, doing this isn't a bad idea at all.

Conversions to interfaces are special in the C# language in such a way that would preclude any particular dynamic object from providing these conversions itself, as well.

I'll think more about what it means to do this and what we can provide for you, though. Thanks!

re: C# "dynamic," Part III

curth — Fri, 07 Nov 2008 19:58:35 GMT

I posted a link to a version of the DynamicObject class that will work with the CTP. It's at http://blogs.msdn.com/curth/archive/2008/11/07/dynamicobject.aspx

C# "dynamic," Part V

Chris Burrows' Blog — Tue, 11 Nov 2008 05:04:24 GMT

Let's look at this: dynamic d = null ; object o = d; // not an implicit conversion Last time , I said

re: C# "dynamic," Part III

Daniel Earwicker — Tue, 11 Nov 2008 17:13:03 GMT

@Steve Cooper

"The example you give makes runtime calls to statically-typed object. It isn't a call to a dynamic object."

The example I give happens to use reflection to make calls to CLR types in its implementation. But it could use the DLR to call dynamic objects, or IDispatch to call COM objects, etc. etc. It could also figure out which of these to use dynamically. The point I'm making is about how the calling code looks: very close to direct method calls, with no need to add further language features.

re: C# "dynamic," Part III

Steven T Abell — Tue, 11 Nov 2008 23:13:09 GMT

Or you could just program in Smalltalk. The question is whether your dynamic program will be wonderfully simple, as in Smalltalk, or abusively complex, as in C#.

It is very interesting to watch the evolution of C# as it recapitulates Lisp and Smalltalk. Language and cultural features that have been around for 30 or 40 years or more, and absorbed a lot of crap from the mainstream cognoscienti for being useless, are now showing up as new and cool. If you really want to see cool, look at and use the originals. They're much better. This assumption that any real programming language has to a) look like C and b) be strongly typed is something we really need to get over.

re: C# "dynamic," Part III

Steve Cooper — Wed, 12 Nov 2008 20:48:58 GMT

@Steven T Abell

I could never get on with dynamic languages. A good, strongly-typed compiler speeds my up my development no end. Your mileage may vary, but I've tried dynamic languages and I've found them slower to develop for, and harder to maintain large programs in.

I think you should keep an eye on C# -- the C# team are clearly all mad for advanced, statically-type functional languages like Haskell and ML, and features just keep cropping up. Where languages like Python and Ruby owe their lineage to lisp and smalltalk, C# is, well, the bastard child of Java and ML. And ML is gaining.

For example, ML-style type inference has made explicit type annotations optional inside C# function bodies. Everything can be declared 'var' and nonetheless be strongly typed;

var i = 0;

var str = "my string";

var obj = new Object();

Lambdas are also nicely integrated, and again use type inference;

var squares = naturalNumbers.map(i => i * i);

The equivalent lisp is both more verbose and less typesafe;

(defparameter squares (map ((lambda i) (* i i)) natural-numbers))

@Daniel Earwicker

You're right -- your version could be updated to call DLR or COM objects happily.

re: C# "dynamic," Part III

Steven T Abell — Thu, 13 Nov 2008 03:44:26 GMT

@Steve Cooper

My mileage does vary. The approach differs, the design differs, the debugging differs, and type errors really aren't a problem very often in good Smalltalk or Lisp. My aversion to type specification is not due to an unwillingness to type, and I understand what can be done with signature matching. I also understand how many problems that are solved by strong typing are caused by strong typing. I prefer languages whose design intent is simple and clear, as opposed to languages that are bags of features. To each his own.

C# "dynamic," Part VI

Chris Burrows' Blog — Fri, 14 Nov 2008 17:20:56 GMT

We left off last time with this piece of code public class C { public static void M( int i) { } public

C# Dynamic - CSharp's new feature of the coming version 4.0

Journal of Abu Sayed Mohammad Ismail — Wed, 24 Dec 2008 09:37:34 GMT

Very good resources for the coming version... Sam Ng Dynamic in C# Part One Dynamic in C# Part Two Chris

C# “dynamic,” Part VII

Chris Burrows' Blog — Wed, 04 Feb 2009 03:35:46 GMT

It has been a while since I posted anything here, and I have the same excuse everyone else does. Work,