I’ve now moved my coding blog permanently (or so I hope) to codeblog.jonskeet.uk. Please go there for new posts – and all my old content is there too, of course. I’m disabling comments on this blog, and will add a conspicuous banner too.
This post is a mixture of three things: Revision of how extension methods are resolved Application of this to task awaiting in async methods A rant about void not being a type Compared with my last few posts, there’s almost nothing to do with genuine asynchronous behaviour here. It’s to do with how the language supports asynchronous behaviour, and how we can hijack that support 🙂 Extension methods redux I’m sure almost all of you could recite the C# 4 spec section 7.6.5.2 off by heart, but for the few readers who can’t (Newton Microkitchen Breakfast Club, I’m looking at … Continue reading Using extension method resolution rules to decorate awaiters
This is a reply to Ben Alabaster’s blog post, which is itself a reply. You can follow the trail yourself. I’ll assume you’ve read the post – I’m not going to go over anything already written there, other than my comments. I took issue with three aspects of Ben’s refactoring: The use of float for currency The fact that "BaseRate" effectively doesn’t have a well-defined unit; in some cases it’s "dollars per hour" and in others it’s "dollars per pay cheque, regardless of hours" smells The use of properties for the pay functions I’ll tackle the last one first, because … Continue reading Reply to a reply… tweaking refactoring
Okay, I know I said that part 4 would be the last part in this series… but since then I’ve not only thought about iterator block parameter checking, but a few other things. Some of these I simply forgot about before, and some I hadn’t thought of yet. I’m not sure any of these are actually worthy of inclusion, but they may provoke further thought. Tuple returns I’ve been reading Programming Erlang and I suspect that being able to return tuples (i.e. multiple values, strongly typed but without an overall predefined type) would be a good thing. For instance, in … Continue reading C# 4, part 5: Other bits and bobs which probably don’t merit inclusion
Last Friday evening was the inaugural Reading Geek Night. More about that another time, but if you’re in or around Reading in the UK, and fancy meeting up with some smart people (and me) to discuss software in various shapes and forms, let me know. After most people had gone home, a few of us including Stuart Caborn were talking about specs. Stuart remembers how I ended up writing some annotations in the C# Annotated Standard: we were debugging some code, and I noticed an unboxing conversion which was unboxing an enum as an int. It worked, but I was … Continue reading The value of a language specification
A while ago, I was directed to a disturbing (in my view) post on GrantRi’s blog, to do with the .NET memory model. I’m slightly less disturbed having read his clarification, but there’s a fairly deep problem here. Here’s part of a sample class: string name; public void WriteNameLength() { string localName = name; if (localName!=null) { Console.WriteLine (localName.Length); } } Now, other threads may be changing the value of name all over the place, and there’s an issue in WriteNameLength in terms of whether or not it shows the “latest” value, but my question is: can the above throw … Continue reading The CLI memory model, and specific specifications
Life has become considerably easier for developers over the years, particularly with the advent of managed code (or whatever the equivalent terminology is for Java). Memory usage is something which one only needs to be aware of rather than constantly being "in your face" in the way it tends to be in C. However, that doesn't mean that all is rosy, or that we can solely concentrate on actual business problems. I thought it might be worth a quick run-down of the problems I tend to find getting the way of more interesting work. In every case things have become … Continue reading Why development is still hard in 2006
A while ago I commented on how I’d like a return? statement, which only returned if the return value was non-null. The purpose of this was to remove the irritation of implementing Equals and IComparable.CompareTo on classes with several properties. For an example of the kind of thing I mean, consider an Address class with properties Country, State, City, ZipCode and HouseNumber. (Apologies to readers who aren’t American – while I feel a traitor to my country for using state instead of county and zip code instead of post code, I’m guessing there are more readers from the US than … Continue reading Elegant comparisons with the null coalescing operator
There’s quite possibly only one person in the world reading this blog who doesn’t think it’s got anything to do with Vista. The windows in the title have nothing to do with Microsoft, and I’m making no assertions whatsoever about how much unit testing gets done there. The one person who understands the title without reading the article is Stuart, who lent me The Tipping Point before callously leaving for ThoughtWorks, a move which has signficantly reduced my fun at work, with the slight compensation that my fashionable stripy linen trousers don’t get mocked quite as much. The Tipping Point … Continue reading Broken windows and unit testing
Introduction Recently, Eric Gunnerson made a post in his blog with the idea of “the seven deadly sins of programmers”. Eric is posting his ideas for such a list one at a time, periodically. He invited others to write their own lists, however, and it was such an intriguing idea that I couldn’t resist. The list is in descending order of importance (I figure not everyone will make it to the bottom of this post) but the order is fairly arbitrary anyway. Hopefully none of this will be a surprise to most of my readership, but it’s nice to write … Continue reading The 7 Deadly Sins of Software Development
