Eric White's Blog : Dynamic Types

Anders Hejlsberg Introduces C# 4.0 at PDC 2008

EricWhite — Wed, 29 Oct 2008 19:41:00 GMT

Anders Hejlsberg presented a fascinating and entertaining session at PDC 2008 on C# 4.0. He talked about dynamic typing, optional and named parameters, improved COM interoperability, and improved support for co-variance and contra-variance. These language improvements are very cool – they enable us to write code that more closely expresses our intent, with less syntactic noise. Carve out some time, and watch his PDC session. Anders is a dynamic presenter, so you won’t be bored!

Dynamic Typing

These guys are brilliant. To support dynamic typing, they have introduced the concept of “statically declaring an object to be a dynamic type.” This allows them to add dynamic typing to a language that is strongly focused on all of the goodness that a statically typed language brings. A dynamic type is just like the “object” type, except with dynamic semantics - member resolution is deferred to runtime.

Perhaps the strongest motivation for dynamic typing is interoperability with dynamically typed languages such as Python, Ruby, and JavaScript. But there are a number of scenarios where you are programming against constructs that are inherently dynamically typed – XML, databases, COM – to list three – that benefit from dynamic typing. And some people feel that they are more productive when prototyping with a dynamic language, and these new language features support them.

One of the most interesting parts of the talk is where he introduced the concept of an interface, IDynamicObject. When you write a class that implements this interface, you can write your own code to get or set members. In his talk, he showed a small class that wraps a Dictionary, allowing you to set or get ‘properties’ – you are actually setting or getting items in the dictionary. Cool.

You also have the ability to treat statically typed objects as dynamic types, and the language will use reflection (with smart caching for performance) to resolve members at runtime. This allows you to write code that is very ‘Python Like’ or ‘Ruby Like’. So, for example, you could write code like this:

public class Product

{

public string Name { get; set; }

public int Age { get; set; }

}

class Program

{

static void Print(dynamic x)

{

Console.WriteLine("Name: {0}", x.Name);

Console.WriteLine("Age: {1}", x.Age);

}

static void Main(string[] args)

{

Product p = new Product()

{

Name = "Bob",

Age = 45

};

Print(p);

}

Optional and Named Parameters

I remember some time ago, I saw a study about developer preferences. Some developers prefer to design classes that can never be in an invalid state, so will write constructors that take a number of parameters, and the object returned from the constructor will always have all required members initialized. They will prefer to construct an object like this:

Product p = new Product("Bob", 45);

However, if, in order to construct a valid object, you must specify a large number of parameters, this leads to somewhat unreadable code. I can’t remember if the xyz parameter is the fourth or fifth parameter to the constructor, and end up relying on Intellisense and tooltips in Visual Studio to tell me which parameters are which.

Other developers prefer to see code that is more readable. However, in the following example, if the Product class requires that the Name and Age properties must always be set, the object p is invalid between the point where it is constructed, and the properties are initialized.

Product p = new Product();

p.Name = "Bob";

p.Age = 45;

With named parameters, you have the best of both worlds. You can write it like this:

Product p = new Product(

Name: "Bob",

Age: 45

);

You get the readability where you can see the parameter names for all values passed to the constructor, and you can write the constructor to enforce invariants.

Optional parameters (which have been around for some time in VB) also remove syntactic noise.

Improved COM Interoperability

They have improved the semantics when importing a COM interface. This combined with the new dynamic typing capabilities and optional parameters results in significantly cleaner code when interacting with COM. In his video, Anders automates Office. He first shows the code as you would need to code it now. Then he cleans it up using the new language features. The difference is dramatic.

Co-Variance and Contra-Variance

In his talk, Anders provides a concise explanation of C# 4.0’s improved support for co-variance and contra-variance. This is a feature (most appreciated by language geeks) that makes the language behave more like we would expect it to in some circumstances involving generic types. Co-variance and contra-variance are two special cases where it is safe to treat a more derived closed type as a less derived closed type. (A closed type is a type where you have supplied a type for a generic type parameter – List<T> is an open generic type – List<int> is a closed type of List<T>.) We can tell the compiler additional information about the use of type parameters, and the compiler can then understand when it is safe to convert a more derived closed type to a less derived closed type. Currently, there are some scenarios where you are forced to use a less type-safe approach. With C# 4.0, these scenarios will become type safe.

I personally ran into this recently when I was writing a little text parser where the structure of the code was parallel to a little grammar that I had defined. I could implement it, but only in a way that was not type-safe.

This is a language feature that will be most appreciated by developers writing more complex class hierarchies that make use of generics. It will impact the rest of us who write code that uses those class hierarchies.

Anders Hejlsberg Talks about C#, Mentions Dynamic Language Features for C# 4.0

EricWhite — Sun, 05 Oct 2008 20:38:00 GMT

In a must-read October 1, 2008 interview with Computerworld, Anders Hejlsberg talks about the history of C#, the motivations behind some of the language design decisions, and mentions that the C# team is looking at supporting dynamic programming.

From the article:

“I think that C# is becoming one of the first widely adopted multi paradigm programming languages out there. With C# you can do object oriented programming, you can do procedural programming, now you can also do functional programming with a bunch of the extensions we’ve added in C# 3.0. We’re looking at C# 4.0 supporting dynamic programming and so we aim to harvest the best from all of these previously distinct language categories and deliver it all in a single language.”

A dynamic type (as implemented in a language such as Ruby or Python) is one where you can at run-time add additional properties, fields, and methods to an existing type. For example, you could have a type that abstracts a record in a table in a database:

class Record

{

private DatabaseTable _table;

public DatabaseTable Table

{

get

{

return _table;

}

public string ToString()

{

// convert record to a string

}

public void Add()

{

// add the record

}

A dynamic type system allows you to set properties on such a type at runtime, even though those properties were not in the class definition:

Record record = new Record();

record.Name = "John";

record.Title = "President";

record.Phone = "800-555-1212";

In Ruby and Python, you can also add methods to a class dynamically. If you try to access a member or method that isn’t part of the class definition, or hasn’t been added dynamically, then the runtime throws an exception.

Note that I have no information yet about the features that the C# team is thinking of adding to C# 4.0. I’ll be attending the sessions on the future of C# at PDC 2008 to learn more. J

I had the occasion to explore dynamic typing some time ago – I spent a little time learning Python and Ruby. I like Ruby better than Python – I’m just not a fan of having white space be syntactically significant. I might like it better if tabs were disallowed, but even so, I like being able to format my programs exactly the way that I want to, without worrying about the semantic impact of indenting. So if you are going to explore a dynamically typed language, I recommend IronRuby.

First of all, you must realize that you (probably) lose the benefits of Intellisense when moving to a dynamic type system. Intellisense is based on the IDE knowing about types, hence only works with strong typing. I remember that when I was writing a few Ruby programs, I had to redevelop an old skill of typing LongVariableNamesVeryAccurately. Since becoming used to Intellisense, I find that my fingers automatically remember that accessing a particular property or method requires that I type 2 or 3 or 4 initial characters of the member. I program faster using Intellisense, even though member names tend to be longer now than in the past.

The .NET Framework Design Guidelines recommend to not use abbreviations or contractions as part of identifier names, hence names tend to be longer, but it doesn’t matter because we use Intellisense so that we don’t have to type the entire name.

The .NET Framework Design Guidelines were derived from the very excellent book, Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, by Krzysztof Cwalina, Brad Abrams. This well-written book should be required reading for all .NET developers.

Also, dynamic typing comes with a bit of a performance hit. However, these days, performance hits are always weighed against the benefits of programmer productivity.

Personally, for many programming tasks, I prefer strong typing, but there is one area where dynamic typing really can excel – when programming against a database or XML. In these cases, you want to have properties that contain the fields in a record, or the child elements and attributes of an XML element. But in a strongly typed language, this means that you must generate code. You have to generate classes with appropriate members, and this brings all of the associated complications – if the underlying database changes, and you don’t regenerate the classes, then you have a mismatch between the underlying data store and your classes.

But the issues change when using a dynamic type system. It means that your objects are instantiated with the requisite properties populated with the correct data. It eliminates the code generation cycle. But of course, this brings with it the issues of run-time failures.

The performance issue is mitigated when using a dynamic type system against a database. The performance issues associated with database access significantly outweigh the performance hit associated with dynamic types.

I’m eagerly awaiting the C# futures sessions.