JavaScript Generators

These work annoyingly well. Why annoying? Because they’re Mozilla specific. If only we could use them all the time. The other thing that’s annoying is how they are actually better than the C# equivalent.

There are two major advantages compared with C#’s yield return.

More on delegates vs interfaces

A commenter on yesterday’s post asked about the lack of Dispose. Here’s a way of doing it:

Threadsafe Interfaces, Delegates vs Interfaces, Stuff Like That

The mighty Skeet posted the other day about the idea of using a single instance of IEnumerable as a shared input for multiple threads (not that I realised at first, but I got there eventually).

Clearly the interface is no good for that purpose, because two operations (“check for existence of next item” and “read next item”) are exposed as separate methods/properties, so it can’t be made atomic. Jared Parsons has blogged a lot of times very readably about this.

This got me thinking, because I’ve noticed that I can often shrink an interface declaration down so it only has one method. And then it doesn’t need to be an interface; it can just be a delegate. That way you can implement it on the fly with a lambda expression. If you express it without any out/ref parameters, you don’t even have to declare a new delegate type. And if you have a Tuple class (as in .NET 4.0), you don’t need to declare any new types – just higher order methods.

How var fixes a type hole in C#

Assuming we have:

public class Base {}
public class Derived : Base {}
public class Unrelated {}

Referential Identity and Internship

I was thinking about a gotcha in Java, and started wondering about the idea of making it convenient to intern reference objects.

Making Lambdas and Iterators Play Nicely Together

The major problem with this idea is in my favourite feature of C#. In an iterator (a function containing the yield keyword), the code is transformed into a state machine represented by a class. It has to be chopped up into sections, so the function can be “paused” after each yield return. Those pieces must all be in the same function, so sadly lambdas don’t play well with iterators.

There are a couple of possible future language features which would completely solve this, however.

What’s Wrong With C# 4.0′s dynamic Keyword, and How I Think It Should Be Fixed

Update: Exactly what I want, already implemented, complete with caching of the call site. Also, Microsoft’s Mads Torgersen responds to this suggestion here.

C# 4.0 proposes to add the dynamic keyword to the language. There are a few problems with it:

Displaying a nested evaluation tree from Expression<Func>

Updated: The downloadable source (see link below) is now tidied up a bit, and also displays any embedded string comparisons in a similar way to NUnit.

This might be useful as a way to write Assert statements in tests. Instead of requiring many different forms of Assert to capture values and intents, we could just have one Assert that accepts a lambda:

A functional replacement for the using statement

The using-statement is just that: a statement. Why does this bug me?

The FileStream object has a Length property. Assuming I have a function Open that returns a FileStream ready for us, it is awfully tempting to do this:

Further Muddying the ForEach Waters

ForEach is regularly proposed as a missing feature in the BCL but has been rejected in the past apparently because it wouldn’t be "functional" enough, doesn’t return anything so calls cannot be chained together in a LINQ-like pipeline, and so on. So here’s a different approach that is undeniably functional, and does support chaining together.