1/27/08

Moving to http://blogs.msdn.com/kirillosenkov

Hi all,

for the sake of consistency with the rest of the C# Team I'm moving my blog over to http://blogs.msdn.com/kirillosenkov. I hope you update your readers and bookmarks and sorry for the trouble. I would be glad to welcome you at my new place.

This blog will stay here as it is, all the posts and comments will remain just in case anyone needs them. However all the new stuff is going to happen there, so you won't miss anything if you unsubscribe from this one.

I have to say, Blogger is a very nice place and I liked it here a lot. I felt "at home" with this blog, I hope to have the same feeling for the new one. Thanks Blogger!

Hope to see you again soon!
Kirill

1/11/08

How to create a generic List of anonymous types?

There was a question on one of the forums asking how to create a list of anonymous types given a single instance of an anonymous type:

            var Customer = new { FirstName = "John", LastName = "Doe" };
var customerList = new List<????>();

My first reaction was to answer that this was impossible, and even if it was, for what purpose, but thankfully people replied before me, who knew better. I was amazed by these ingenious tricks. For example, Kael Rowan suggested:


            var Customer = new { FirstName = "John", LastName = "Doe" };
var customerList = (new[] { Customer }).ToList();

customerList.Add(new { FirstName = "Bill", LastName = "Smith" });

I think this is brilliant! This technique is called casting by example. Here's another implementation, using a "list factory":


        static void Main(string[] args)
{
var Customer = new { FirstName = "John", LastName = "Doe" };
var customerList = MakeList(Customer);

customerList.Add(new { FirstName = "Bill", LastName = "Smith" });
}

public static List<T> MakeList<T>(T itemOftype)
{
List<T> newList = new List<T>();
return newList;
}

They use generic type inference here to "name" the anonymous type to T and return a List of it.


This somewhat made me think of var as a black hole - once a type is being "converted" to a var, it can never come back explicitly (well, unless you want to cast :) It can reappear in another method as another "var" (casting by example) or be remanifested as inferred generic type parameter, but it can't get an explicit name ever again.


There was a discussion a while ago (between Wilco Bauwer, Rick Strahl and yours truly), whether C# should extend type inference to return types of methods, types of fields, properties etc. : Returning var from a method in C# 3.0 Generally it was agreed that this would not be a good thing to do, for various reasons. Eric Lippert gave a good summary of all the trouble it might bring:



  • what if languages consume the method, which don't support type inference?

  • how to store this in CLR metadata?

  • how to detect versioning problems once you update your class?

  • how to deal with two structurally identical types from different assemblies?

  • etc.


My personal feeling about this all (which sort of corresponds with the general consensus), is that one shouldn't use anonymous types for more than trivial LINQ operations. If a type is going to be reused, give it a proper name and declaration. Anonymous types don't scale (at least, not in C# 3.0).


If there is ever going to be a C# feature to use var as a return type of members, this is going to be the first time ever I'll want the C# team not to implement a feature :)

12/17/07

Delegates as an alternative to single-method interfaces

I noted some time ago that one can use delegates instead of interfaces that contain one method. In fact, I think delegates are more flexible when compared to single-method interfaces and I'll try to explain why.


The scenario

As a reminder, the discussion started with this post: Making ICollection inherit from more fine-granular interfaces. What was the problem? I wanted to design a method that adds a large amount of data to some collection. The method would possibly serve all sorts of different clients (callers). A very reusable solution would be to just return the items so that they can be added by the client (on the caller's side), but that would mean:

  • Clients have to do additional work of adding the items to their collections (duplication of code with the same intent)
  • This also costs at least double performance (each element is first put into a temporary storage, and then put into the target storage, which gives us O(2n))
  • The method had to accumulate the items before returning them (O(n) memory consumption for the returned values (List<T>, ReadOnlyCollection<T> or whatever)
  • Even in case of yield return, where O(1) temporary storage for return values is required (values are being returned lazily one-by-one as they are needed), you'd still have to add those values to the target collection, sooner or later

That's why I decided to go for a void method that accepts a collection where to add the items (to avoid performance penalties). My first implementation accepted the ICollection<T>, the .NET framework's most probable candidate for a thingy that has an 'Add' on it. However, ICollection<T> is not good enough, because not all the types that have 'Add' on it implement ICollection<T>. There was some buzz on the blogosphere about duck-typed implementation of collection initializers in C# 3.0 - a good example of a place where we definitely lack the ISupportsAdd<T> interface or something like this.


The Solution with Delegates

To make long story short, here's a what I think a good solution to the problem. Instead of having the interface:

interface ISupportsAdd<T>
{
void Add(T item);
}
it is enough to use the System.Action<T> delegate. Compare the old way and the new way:
void OldAdd<T>(ISupportsAdd<T> collectionToFill)
{
collectionToFill.Add(item1);
// ...
collectionToFill.Add(item100);
}

void NewAdd(System.Action<T> addMethod)
{
addMethod(item1);
// ...
addMethod(item100);
}
And on the caller's site:
// The target collection can be anything
// that has an "Add" method
// (which can even be named differently)
List<int> resultsToFill = new List<int>();

// Don't pass the entire collection
// when you are only going to use
// the Add method anyway!
// Only pass the Add method itself:
NewAdd(resultsToFill.Add);

See, that easy. Just pass the "pointer" to the Add method of your choice and the NewAdd method will call it as many times as there are items!

The important lesson I've learned from this: to make a piece of code reusable (in this case, a method), one should only provide as little information to it as it is necessary.

Earlier I tried to do that subconsciously by demanding more "fine-granular" interfaces - only to provide as little information about the type as necessary (we were not going to use Remove() anyway, so why provide it?).


Delegates - "interfaces on a member level"

Now I've realized, that in case where you only need to use one method, you can go even more granular - no need to pass the type, just pass a member (members are more fine-granular than types). See how it already starts to smell a little like duck-typing? You don't have to declare a necessary interface, your existing type signature is just fine, as long as you provide the necessary member. This is an awesome bonus feature in C#. Unfortunately, it is only limited to one member, and even more, that member has to be a method! (No delegate properties, pity, isn't it?)


Delegates vs. single-method interfaces

To summarize, there has been ongoing talk in the blogosphere about adding an implementation of an interface to an existing type without changing the type itself. There is a desire to automatically or manually make the type implement some interface, as soon as it has all necessary members with the right signatures. C# currently offers a solution, but only if your "interface" consists of exactly one method - you can then use a delegate to that method and pass it around. Delegates in this case are semantically equivalent to single-method interfaces - you can pass around both and you can call both. But delegates are more flexible, because you can take a delegate ("pointer") to an existing type (its method actually) without changing it, and you can't make an existing type implement your interface without changing it.

12/8/07

DG 1.0 - free Dynamic Geometry Software for kids

Dynamic geometry is a piece of software for exploring interactive math constructions directly on your screen. It lets you create any ruler-and-compass constructions using your mouse or stylus. It also allows you to play and experiment with the drawing using drag-and-drop (this is not possible on paper).

 

 

The points in the drawing are actually draggable - as you drag a point, the triangle will change with the rest of the construction. You can create hyperlinked and commented interactive documents:

and live measurements:

 

Download

If you're interested (or you have kids who currently study geometry), you can download DG 1.0 from my website: dg.osenkov.com. The software is free and no setup is necessary, just unzip the archive to any folder and run Geometry.exe. Please let me know if you have any questions or feedback, I'd be happy to help.

 

A bit of history

For the curious ones, DG is a piece of software I wrote in 1999-2002 when I was working for the Kharkiv pedagogical university in Ukraine. A great team of teachers, methodologists and mathematicians worked on this software package, which includes more than 250 interactive drawings to support the school geometry course. I was the only programmer on the project with about 5 PMs and 5 testers :) It is great to know that DG is still being used in many ukrainian schools in geometry lessons, after we shipped the software in summer 2002. The idea of dynamic geometry dates back to 1980's, there are many dynamic geometry programs, so I'm not saying we invented anything new. But we implemented DG to specifically suit the needs of ukrainian teachers and students, and it also turned out to be a pretty good piece of software for everyone else to use. So I decided I'd blog about it, so maybe it could be of some use to someone.

 

Although it has been more than 5 years after we shipped DG, I still sometimes receive feedback from teachers. I'm always happy to see anyone using DG, because I put a lot of soul and effort into this project at that time. Thanks to this project, I grew from being a geeky teenager that I was in 1999 into an experienced developer who shipped and deployed working and tested software in 2002 that still works in 2007 :) I'm very thankful to our project leader, Sergey Rakov, who I also respectfully consider my personal Teacher.

11/29/07

Please use File.ReadAllText and the like

Starting from .NET 2.0 the basic file read/write API is finally implemented how it should be. I noticed that some people are still using the old way (StreamReader & Co) so I highly recommend the static methods

  • ReadAllText
  • ReadAllLines
  • ReadAllBytes

and

  • WriteAllText
  • WriteAllLines
  • WriteAllBytes

on the System.IO.File class.

Thanks :)


Update: I'd like to correct myself. Thanks to kerneltrap (see comments below) I'm not suggesting people should always use File.ReadAll* as opposed to the stream based approach, but this makes a lot of sense for simple and small files you'd normally read in one step, for the code readability reasons.

Of course, if you are doing non-trivial file operations, using using+StreamReader/Writer is better for performance reasons, and you don't have to load the entire file in memory this way. I was just seeing some cases where it was needed to read a small (10 KB) file into a string, and StreamReader.ReadToEnd was used for this purpose. So I'm sorry for not clearly expressing what I actually meant :)



kick it on DotNetKicks.com

11/27/07

Extension methods: one of my favorite C# 3.0 features

With C# 2.0 I sometimes had a feeling that something bigger is coming. As it now turns out, it was C# 3.0 (surprise!). Now the whole picture makes perfect sense, all the features start playing together seamlessly and I have to say that it is an awesome release. LINQ is a fundamental breakthrough and all the machinery that was required to implement it is great as well. I especially like extension methods, because they allow me to write more concise and expressive code than earlier.


Enhancing existing APIs


Before C# 3.0, the creator of an API or a framework was solely responsible for the readability and the usability of the API. Users of the API had to consume available methods as they were, unless they were ready to build own facades, adapters or decorators. Now the clients of an existing API can significantly enhance its readability, expressiveness and usability without even changing a single bit about it.


Addind default implementation to interfaces


Another advantage is similar to type classes in Haskell - ability to add some default implementation to existing interfaces. The best example for this is IEnumerable<T>, which now boasts so much more functionality than earlier! And note: we haven't changed a thing about IEnumerable<T>, we just added some stuff somewhere else, and all IEnumerable<T> implementations suddenly became so much more powerful. As we know from my previous posts, this is like adding 'mixins' to the language - just implement the interface, and you get this default functionality for free.


Composability and fluent interface


Also, an important advantage of extension methods is that they can be called on null objects without any NullReferenceExceptions. The best example for this is of course the string.IsEmpty() method:


        public static bool IsEmpty(this string possiblyNullString)
{
return string.IsNullOrEmpty(possiblyNullString);
}


This simply boosts composability because we don't have to check for null before actually calling a method on an object - we can do it inside the extension method. Earlier, callers were responsible to check for a null object every darn time they wanted to call an instance method on that object. Now, if we can gracefully handle a null object without throwing (e.g. just return null), it saves so much effort on the caller's side. As I said, our calls become truly composable, for example, I can chain calls to Object1.Method2().GetObject3().TryAndGetObject4().OhAndPerhapsTryGettingObject5AsWell() without worrying that one of the methods might return null. If it does return null, the whole chain won't throw and will just return null. Of course, there can be a lot of pain debugging this thing because we don't save intermediate results, but this is still a huge enabler for People Who Know What They Are Doing. This composability is a also a nice helpful feature for designing Fluent API (speaking of fluent API... what about extension properties??)



Extension methods in action: populating and grouping TreeView items



Now let me show a couple of delicious examples. I had an interesting problem recently. There was a list of objects (say Cars), each of the objects had four properties. Let's say like this:


    class Car
{
public string Make { get; set; }
public string Model { get; set; }
public int Year { get; set; }
public Color Color { get; set; }
}

Now, I had to add all Cars from the list to a WPF TreeView control, and hierarchically group cars by Make (similar makes go under a single node), then by Model, then by Year, and finally by Color. This is actually a pretty good interview question, and as I usually totally suck at interview questions, I started building an overly complicated strongly typed object model to represent a MakeGroup (based on Dictionary), which contains a ModelGroup, which contains a YearGroup etc. etc. I would then use LINQ to query over the master car list, group by make, for each group create a MakeGroup object, etc. etc. After building the object model was done, I would walk it with a special TreeViewItemBuilder that would build the treeview items and nest them correspondingly. After about 1,5 hours of this mess (unfortunately, interviews usually last less than 1,5 hours) I got struck by a what I think is an excellent idea. I wrote this extension method:


    public static class WPFExtensions
{
public static TreeViewItem FindOrAdd(
this ItemsControl parent,
string header)
{
// try to find an existing item with this name
TreeViewItem result =
parent.Items.Cast<TreeViewItem>()
.FirstOrDefault(x => x.Header.ToString() == header);

// if not yet there, don't throw, just create it in place
if (result == null)
{
result = new TreeViewItem { Header = header };
parent.Items.Add(result);
}

// and return
return result;
}
}

Now, I threw away my overly engineered "solution" and came up with this instead:


            foreach (Car car in GetCars())
{
treeView1
.FindOrAdd(car.Make)
.FindOrAdd(car.Model)
.FindOrAdd(car.Year.ToString())
.Items.Add(new TreeViewItem { Header = car.ToString() });
}

These are 8 lines instead of 200+ I wrote first. This is much more manageable and flexible than my original solution - you can easily change the code to e.g. first group by Model, then by Name - by swapping two lines of code. If you're interested in the full source code of this sample, just leave a comment and I'll post it here (that's what I call lazy sample upload - long live the functional approach!). Beside extension methods, this sample also demonstrates: auto-implemented properties, object initializers and lambda expressions! Try and spot them all!


More examples


I'll go ahead and post more examples of extension methods and how they help me write cleaner code everyday.



1. Collections


It's nice to be able to check if a collection doesn't contain items in a single step:


        public static bool IsEmpty<T>(this ICollection<T> possiblyNullCollection)
{
return possiblyNullCollection == null || possiblyNullCollection.Count == 0;
}

ICollection<T> lacks AddRange:


        public static void AddRange<T>(this ICollection<T> collection, IEnumerable<T> items)
{
foreach (var item in items)
{
collection.Add(item);
}
}

Or adding several items separated by commas:


        public static void Add<T>(this ICollection<T> collection, params T[] items)
{
foreach (var item in items)
{
collection.Add(item);
}
}

It's nice to be able to call a given method for each element:


        public static void ForEach<T>(this IEnumerable<T> collection, Action<T> action)
{
foreach (T item in collection)
{
action(item);
}
}

Or have a composable GetValue on Dictionary that doesn't throw:


        public static V GetValue<K, V>(this IDictionary<K, V> dictionary, K key)
{
V result;
if (dictionary.TryGetValue(key, out result))
{
return result;
}
return default(V);
}

2. Strings


For strings, everyone already seems to have developed their own little library. So I think I won't be original if I share these:


        public static bool IsEmpty(this string possiblyNullString)
{
return string.IsNullOrEmpty(possiblyNullString);
}

public static void Print(this string str)
{
Console.WriteLine(str);
}

public static void MessageBox(this string str)
{
global::System.Windows.MessageBox.Show(str);
}

I also found it to be very convenient to have the following (trivial implementation, doesn't throw):



        public static int? ToInt(this string textNumber)
public static bool? ToBool(this string boolValue)

These guys rock because they easily compose and don't distract me with the necessity to call TryParse or such. BTW I think that the composability of any TryParse method is not very good, in case you haven't noticed.


3. XML


Last but not least, a nice enhancement to XElement:


        public static string GetElementValue(this XElement element, string elementPath)
{
if (elementPath.IsEmpty())
{
return element.Value;
}

XElement subElement = element.Element(elementPath);
if (subElement == null)
{
return null;
}

return subElement.Value;
}


It doesn't throw, which saves me a lot of effort every time I want to call it - I don't have to be afraid that Element() can return null.


Conclusion


Of course, there are caveats. Many people critisize extension methods for the lack of discoverability. Indeed, extension methods for a type only appear in the Visual Studio IntelliSense if you add a using declaration with a namespace where the extension methods are declared. This is currently a discoverability problem.


Also, others mention that it is difficult to read existing code with extension methods because we don't know the meaning of methods and where they are declared. My answer - use F12 (Go to Definition) in Visual Studio.


Finally, there is a versioning problem.


But still, I think extension methods are so cool and they provide so many advantages, that it is well worth using them anyway. Especially if you belong to those people who Know What They Are Doing.



kick it on DotNetKicks.com

11/23/07

Jacob Carpenter on named arguments in C#

Jacob Carpenter has an interesting post called Named parameters { Part = 2 }. As immutable types are very trendy these days (good!), questions arise how to initialize them. C# 3.0 has Object Initializers (where IntelliSense even kindly shows you the list of remaining uninitialized properties), but unfortunately we cannot use it because it requires the properties to be settable. Jacob came up with a pretty cool trick to use anonymous types to get a syntax similar to object initializers and still call into a constructor. This technique is somewhat similar to casting by example, where we also abuse anonymous types to reach our goal.

To further improve Jacob's strategy, I would probably turn NamedArguments into a factory and make it responsible for instantiating the CoffeeOrder object as well. One could use Activator.CreateInstance to create an instance of the CoffeeOrder type and return it directly instead. Thus, the code for initializing the object could be further reduced to:

var order1 = NamedArgs.For<CoffeeOrder>(new
{
DrinkName = “Drip”,
SizeOunces = 16,
});

11/16/07

John Rusk on Extension Interfaces

Sorry for not blogging recently, I was ramping up and getting started in my new role on the C# team. I love it here! The people are great, the job is interesting and I'm really proud to work in C#. There are a lot of interesting things starting here, like F# or other very exciting projects I can't talk about at this point ;-)

 

I posted recently about duck-typing and extension interfaces. John Rusk pointed me to his great article about extension interfaces. It was posted back in 2006 but I only discovered it recently (sorry). It was interesting to see Keith Farmer's comments on the article, especially because I'm now sitting two offices down the hall from him so I could go and ask him what he thinks about it in person. But I digress.

 

I like John's ideas and considerations, and I currently can't think of any caveats of implementing extension interfaces from the design point of view. From the implementation perspective, there might be a complication John warns about. To make an existing class implement an interface, you'd usually write an adapter class. Now the problem is: a reference to the adapter object won't be the same with a reference to the actual target object, and that might become a problem, e.g. when you'd like to compare objects. Being constructive, John also points to a possible solution involving CLR internal special cases like TransparentProxy (see an as-always-excellent post by Chris Brumme about it).

10/12/07

I joined the Microsoft C# team

A couple of weeks ago I moved from Germany to Redmond, WA to join the C# IDE team. I have become an SDET (test developer) on the IDE QA. Areas we own are the editor, syntax highlighting, IntelliSense, refactoring, Edit and Continue, Class View, Solution Explorer, etc. We do not cover any designers (such as the WinForms designer) and parts of the IDE not related to the C# language.

As you might have noticed from the contents of this blog, C# team is probably the most interesting place within Microsoft for me to work at. After my first week, I have to say that I'm really happy to be here and to meet amazingly smart and passionate people working on the stuff I'm most interested in.

I hope to continue blogging and to improve the quality of my postings, to keep up with the rest of my new team. If you're interested in that, I'll give a couple of links into our teams blogosphere. Using transitive closure, you can find the remaining C# blogs by following links from there.
  • Charlie Calvert is the community PM of the C# team and his blog is always an interesting resource to watch, because it accumulates other resources and is a recommended entry point to the C# blogosphere and community.
  • Rusty Miller is the C# test manager and has a couple of great posts about how we test C#. That way I could learn something about our team before coming here.
  • Gabriel Esparza-Romero is my manager and a great person to work with. He hasn't posted recently but I will still keep an eye on his blog :)
  • Eric Maino is also an SDET on our team and he helps me getting up to speed and ramping up.
  • CSharpening is a new blog of the C# QA team.
  • C# bloggers is the MSDN list of the bloggers on our team, unfortunately very far from being a complete list. I'll see who I have to bug here to have this list updated.
  • You will find links to many more great blogs from our team and from outside - in the rightmost column of my own blog. I highly recommend all of them, plus any other blogs I might have missed and still have to discover.
Oh, and feel free to contact me with any questions or feedback, I'd be happy to do my best to answer.

Thanks!
Kirill