The Dumping Ground

Steve has noticed, via Don Box, that continuations are getting popular. I can tell you from personal experience that there is a ton of value to continuations in multiple arenas, not the least of which is web serving. Apache Cocoon has supported continuation-driven application flow for its web applications for quite some time now, either using Flowscript (ECMAScript with continuations, done in Rhino), or via JavaFlow (which is currently beyond my ken). Flow makes it amazingly easy to model complex behavior using the standard programmer-friendly syntax of loops, conditionals, and function calls. It's brilliant!

And in some other work I'm doing right now, I desperately wish for continuations in C#. I am attempting to asynchronously decode buffers into message structures, and the painful callback-based approach used by .NET's Begin/End/IAsyncResult approach makes it extraordinarily difficult to code. In order to avoid blocking a thread, I am forced to either stitch together a confusing chain of callbacks, or read data in a larger blocks. The problems with the former are lack of understandability and difficult debugging, and the problem with the latter is that message parsing often requires small chunks to be read to determine how much more is to be read to complete the message.

I yearn to be able to write code like the following, despite my unwieldy made-up syntax and lack of error checking.

Message Decode(Stream stream) {    BinaryReader reader = new BinaryReader(stream);    Message msg = new Message();

   msg.Foo = Continuation.CallWithCurrent(reader.ReadInt32);    msg.Bar = Continuation.CallWithCurrent(reader.ReadInt32);

   return msg; }

Then, the BinaryReader would support something like this:

void ReadInt32(Continuation continuation) {    // Set in the constructor.    this.stream.BeginRead(this.buffer, 0, 4, delegate(IAsyncResult result)    {       this.stream.EndRead(result);       int result = this.ConvertBufferToInt32();       continuation(result);    }); }

I could write my deserialization function as a nice procedural list of instructions, and not have to worry about blocking a thread while I wait. You could, of course, push the continuation call farther down the stack into the stream or socket or from whatever is being read.

In the little free time that I have, I have been messing around with writing a .NET program to help me with the large amount of photo metadata editing I want to do on all the photos I've been uploading to my Flickr photostream.

It's been fun doing some .NET again. It's easy to forget how nice of a language C# is especially with all of the fancy new features 2.0 brings. Last night, I came up with a fun little method of using iterators.

Here's the scenario: I need to collect photo IDs for editing. As a simple solution, I have a very small dialog box that contains a text field, an "Add Another" button, a "Done" button, and a "Cancel" button. When the user clicks "Add Another," I want to save the entered photo ID and re-display the dialog. If they click "Done," the currently entered ID should be saved, and the dialog should vanish. Finally, if they click cancel, the current ID does not get saved, and the dialog disappears.

I have set up the DialogResult of the "Done" buttton to return with DialogResult.OK, and "Add Another" to return with DialogResult.Yes. Here's the code in the UI controller responsible for coordinating this: public IEnumerable GetPhotoIds() { AddPhotoDialog dialog = new AddPhotoDialog();

DialogResult result = dialog.ShowDialog(this.parentWindow);

while (result == DialogResult.Yes || result == DialogResult.OK) { yield return dialog.PhotoId;

if (result == DialogResult.OK) { yield break; }

result = dialog.ShowDialog(this.parentWindow); } }

Then, in the top-level UI controller, I can simply do: AddPhotoUIController controller = new AddPhotoUIController(this.mainForm);

foreach (string photoId in controller.GetPhotoIds()) { PhotoInfo info = this.FlickrApi.PhotosGetInfo(photoId); this.CurrentBatch.Containers.Add(new SinglePhoto(info)); }

Pretty slick. I wish they had made this feature more general, though, and implemented full-on continuations.

I'd like to comment on Steve's post on the WS-* standards process, specifically on how the standards have been produced. A "real" standards process may or may not add any significant value to any given standard. Quite frankly, it depends a lot more on the people involved than anything else. What a "real" process certainly adds is a lot more time until the standard is released. Almost by definition, standards are required to be the least common denominator of functionality, and deriving that LCD is hard work. But the world of web services is amazingly fast-paced. It seems like XML was just barely gaining its foothold in people's brains and suddenly people were talking about SOAP and services. After that, we jumped into warp speed with everybody and their brother suddenly working together on WS-Security, WS-Trust, and all the others. And as Steve points out, while the standards may not be "real," they are real enough that different vendors bits can talk to one another.

All of this reminds me of my college networking class. Frank taught us about the 7-Layer OSI Model for networks (what Chris joking refers to as "The Burrito"). The OSI Model was hashed through and arduously toiled over by the major industry players until it was agreed upon by all. And afterwards, there was much rejoicing!! Now everybody could understand how networks were to be constructed, and a new era of interoperability was born!

And then Frank told us to forget about the OSI Model. Nobody used it. The standard had been stillborn. While the industry had been fighting, the ARPANET, using a much simpler model, had proven Good Enough. It was so Good Enough, in fact, that it eventually became the Internet that we all now know and love. Nobody uses any other kind of network!

The moral of the story is that Good Enough running code will usually produce a de-facto standard that will trump everything else. Why bother with a full standards process for the Web Service languages? They are Good Enough as it is, despite the myriad of pitfalls we are sure to uncover in the future. And I have full faith in the community of developers to continue to produce such de-facto standards provided corporate politics and short-term profit are not allowed to trump the engineers' best judgements.

Read that again.

The community of developers will continue to produce such de-facto standards provided corporate politics and short-term profit are not allowed to trump the engineers' best judgements.

Be careful. It's already happening. Some of the competing WS-* standards, such as WS-Eventing and WS-Notification, seem to exist primarily because companies are competing for control of the specs. Such fractures must be kept to a minimum if collaborative, chaordic engineering is to ever produce de-facto standards as successful as TCP/IP.

It is a rare environment when Getting Things Done is universally accepted as more important than Protecting Your Turf. We all need to keep the pressure up on the corporate powers-that-be to continue the cooperation that has so far proven very successful.

How many times have you written a piece of code like this?

public void Jump(string msg)
{
   if (msg == null || msg.Length == 0)
   {
      throw new ArgumentNullException("msg");
   }

   // Jump!
}

I don't know about you, but I write code like this all the time. It's an important sanity check, and Microsoft recommends it. But what happens if you change the name of the variable msg? Suddenly, your code is wrong. Sure, it's syntactically correct and will compile just fine, but there is no longer a semantic link between the message returned by the ArgumentNullException and the code from which it was thrown.

I propose the addition to the C# language of the nameof operator. Analagous to the existing typeof operator, the nameof operator will return the name of its operand as a string. The example from above, then, would be rewritten as follows.

public void Jump(string msg)
{
   if (msg == null || msg.Length == 0)
   {
      throw new ArgumentNullException(nameof(msg));
   }

   // Jump!
}

It is important to note that the operand is still a full-fledged symbol. Thus, in the example above, changing the name of the msg parameter will cause a compile-time error if the operand to the nameof operator is not also changed. The nameof operator will simply be syntactic sugar, and requires no changes to the CLR, and therefore also causes no change to the run-time performance of the code.

Why is this important? After all, the above example is simplistic, even though it is a common case. First of all, there are many more complicated cases that can occur. As we all know, detailed error messages can go a long way towards helping troubleshoot and debug problems in our code. My own personal guidelines for creating error messages are:

1. Error messages must be unique to a given error condition. You should never copy-and-paste error messages unless the root cause of the error really is identical; and in that case, you should think about refactoring your code because it sounds like you have some code duplication. (The exception to this (pun intended) is the catch syntax, which requires multiple blocks to catch exceptions that do not have the same root.)
2. Error messages must have a detailed message explaining cause of the problem, including the names and values of any variables used to calculate the error condition.
3. Error messages should include a description for how to correct the problem. This could be as simple as giving example known-good values, or it could be as complex as describing how to fix your Windows certificate store to have the right permissions.

The nameof operator will go a long way towards ensuring consistency between error messages and code.

The other need for the nameof operator is the increasing intelligence of the development tools. Refactoring tools have are quite in vouge, evidenced by the fact that Whidbey will be shipping with such tools bundled in. As we continue to do less and less manual editing of our code, relying on a developer's eye to find and fix such problems becomes more and more dangerous.

I came up with this idea when I was at Avanade working with Steve, but I've never mentioned it publicly. As I recall, at that time, Steve had the opportunity to have a quick chat with Anders Hejlsberg, the lead designer of C#, and he mentioned this. I seem to recall he liked the idea, but it was one of those little things that would probably never happen. Steve, am I making this up?

I was able to successfully de-compile and re-compile my MoleMan executable using FileDisassembler. It has a few problems generating incorrect code, although I assume that has more to do with Reflector's de-compilation API than the plugin itself. Mostly, they centered around implicit operators, although it also forgot to add several necessary using statements.

Overall, I'm very pleased. Now I just have to go through and re-name variables and such to something less nonsensical.

When I was still at Avanade, I wrote myself a little program called MoleMan to manage my SSH tunnels. It was really useful because I would often disconnect from the wired network and go wireless, and I wanted my tunnels to automatically re-connect. However, when I left the company, I accidentally left the source code on my laptop, which got wiped. All I had left was my binary install of the latest version that I had installed at home.

Fortunately, I had sent my friend Greg, of Neko fame, a copy of my source code a few weeks earlier. Well, there are a couple of bugs in MoleMan, and I want to fix them and release the program to others who might find it useful. Unfortunately, I have discovered that I made some major changes to the program between the time I sent Greg the source and the final version I'm running. So I need a decompiler.

I found a good list, but unfortunately none of the free tools will do an entire assembly in at once. And everything else is not free.

Does anybody know of a good, free C# de-compiler that will do entire assemblies at once? If so, please let me know.

Update: I have discovered the FileDisassembler plugin for Reflector. Contrary to the name, it actually does de-compile, and it seems to generate pretty good code. I'll start from here and see how it works.

I have been working on a project at home for which I am using DotNetMock to create mock objects for my unit testing. Unfortunately, DotNetMock has a couple of problems with its dynamic generation features. The first is that it does not currently support methods on inherited interfaces, and the second is that it does not work correctly with non-primitive value types.

So I fixed those two problems. Hopefully my two patches will get rolled in.

DotNetMock seems to be the extension of NMock. Many of the interfaces are the same, and NMock hasn't been updated since last May. However, there seems to be only one guy on the DotNetMock project, so I'm not sure how long-term the project is.