Feeds:
Posts
Comments

Archive for February, 2010

I’ve been hard at work on a new version of Onyx. I’ll write another post later explaining why I’m “starting over” and what the new goals are, as that’s not relevant to this post. Since I am starting over, though, it’s given me a good opportunity to switch to using .NET 4 and the new technologies available with it. One of the more exciting new features that I’m very excited to utilize is the new Contract system which brings Design by Contract (DbC) to the .NET world.

DbC was first implemented in the Eiffel programming language, and was discussed in length in the book Object Oriented Software Construction by Bertrand Meyer. DbC is a design and development methodology intended to try and ensure software correctness. I’ve been intrigued by DbC ever since reading about it in OOSC about 10 years ago, but since the idea really requires language support and so few languages include this support (Eiffel being the only one I’ve even written a “hello world” program in), I’ve never really had the opportunity to “use it in anger”. Now that DbC is going to be available in .NET, I can finally get some real world experience with it.

So, what is DbC?

DbC is a way to design, build, document and verify software based on the idea of contracts. In the legal world a contract is used to specify what two parties agree to exchange (goods or services). In DbC contracts are used in the same way. The consumer of a routine agrees to provide certain input, while the routine agrees to provide certain output. The stronger both sides of this contract is specified, the more robust and reusable the code will be. When the contract is codified in the software, it’s possible to use tools to statically verify the correctness of the code, to produce unit tests, and to provide runtime exceptions when the contract is violated. When the contract is well documented, it’s easier to write code that consumes it. All of this leads to higher quality code.

In DbC, contracts are codified using special assertions in a declarative fashion. Methods are decorated with two types of assertions: preconditions and postconditions. The preconditions specify what a caller is required to do, while the postconditions specify what the method will ensure at the end of the call. These assertions are specified using predicates. In .NET 4 these assertions are specified using calls to methods on the static Contract class. The Requires overloads are used to specify the preconditions, and the Ensures overloads are used to specify the postconditions.

Now’s a good time for an aside. I made two claims earlier about DbC that seem to be contradicted by what I just said about how you specify assertions in .NET 4. First, I said that assertions are declarative, while the use of the Contract class appears to be imperative. Second, I said that DbC requires language support, while the Contract class appears to require only library support. I didn’t really get either of these claims wrong, it’s just that Microsoft found a very unusual way to support DbC in .NET. They use an IL rewriter to modify the binary output after it has been compiled. This allowed them to introduce DbC to all .NET languages, even those that don’t have built in support for the concept, while retaining backwards compatibility.

Because assertions are really declarative, despite the novel implementation provided in .NET 4, there’s some restrictions on how you are allowed to write them. They must be placed at the beginning of the method, and need to follow a certain order: Requires then Ensures.

OK, that covers the declarative nature, but what about the claim that language support is required? Why would language support be necessary? We’ve been using library based assertions for a very long time in nearly every language imaginable, after all.

Well, to understand this claim, you need to think about inheritance. Type inheritance obviously requires language support, and contract inheritance isn’t any different. The assertions for a base class method apply equally to overrides in a derived class, and that’s nearly impossible to achieve without language support. Well, the IL rewriter provides this same support without changing the language. Neat, huh?

We should discuss contract inheritance a bit. See overrides may not have the exact same contract as the base. However, the contract needs to be “compatible”. Thinking hard about this, we can come up with some rules. Let’s first think about the preconditions. If the preconditions are identical, we obviously have no problems. What if we add to them (making them stronger), though? This won’t work. Using polymorphism, if a derived instance is passed to a method expecting a base instance, it could violate the stronger requirements because it knows nothing about them. What if we remove some requirements (making them weaker) instead? This is fine, because when the method taking a base instance obeys the base requirements, it will still meet the derived class’s requirements.

Now, let’s think about the postconditions. What happens if we add new conditions (making them stronger)? This is fine, because we’ve still met the base requirements. What about removing conditions (making them weaker)? This doesn’t work, because we may not satisfy the base requirements.

So, in theory at least, we can weaken the preconditions, and strengthen the postconditions. However, in .NET 4 they’ve only allowed us to strengthen the postconditions. The justification they give is that “in practice” there’s rarely a need to weaken the preconditions, and supporting this concept is too complicated. I’m not sure if this justification is valid or not, as I’ve little experience with DbC, but that’s what we have.

So, now we have preconditions and postconditions. There’s a third type of assertion that’s very important: object invariants. Object invariants are assertions about the state of the object between calls to methods on it. These assertions must hold before and after every call to instance methods on the object. In .NET 4, object invariants are supported by decorating methods that specify the invariants (through calls to the Invariant method on the Contract class) with an attribute (ContractInvariantMethodAttribute).

So, there’s a lot of theory. Next, we’ll try to look at the practice of using DbC in .NET 4.

Read Full Post »

New Toy

The family just took a vacation, spending an entire week in an indoor water park and resort. Specifically, we went to Kalahari in Sandusky, OH. We had a great time, though I don’t think I’ll go down any more “toilet bowl” slides.

Anyway, before leaving for this trip, my wife decided we needed a laptop. We own an aging Toshiba (don’t recall the model), but it’s painful to use. It’s that old. See, as much as I’m into this tech stuff, we’re kind of tight with our money. In this case, though, the wife really wanted to stay connected while we were gone on this extended vacation, so as long as we watched the budget, it was time to purchase a new laptop.

Well, we found a deal. Got a Toshiba Satellite U500 at a really great price. I’ve always liked the Toshiba line of laptops (our first one actually got dropped down a flight of stairs, while running, and suffered no damage), so it was pure luck that while bargain shopping with a single day to make a purchase, the one we found was a Toshiba. Even better, this one has a multi-touch screen. I must say, after using this one, I don’t think I’ll ever own a laptop without a multi-touch screen again. I’ve never plugged a mouse into this one, and I’m quite happy about that!

The U500 is a good size. Having bad eyesight, I didn’t think I’d like a screen this small, but honestly, it’s just about perfect. It’s got a rugged design, with a quality feel. It’s also packed with features. I’ve really been enjoying using this thing, even if I do still prefer the desktop experience (may have to look for a multi-touch screen for my desktop now).

I’ve even managed to get some Onyx vNext coding done on this thing, which is something I never could have done with the old laptop. 🙂

Read Full Post »

OK, this is too cool.

My current pet projects, Specificity and Onyx, both require desktop and Silverlight support (well, Specificity is getting this support soon). The typical way of accomplishing this is through project links. You create two projects, one for the desktop and one for Silverlight. You create physical source files in one of the projects, then in the other you create project links to the other file. A project link is like a symbolic link in file system vernacular, but done strictly within a project definition. If you need the code to be different between the platforms due to differences in the platform libraries, you either use conditional compilation via #if/#endif blocks, or you use a partial class with platform specific code in a file not shared with the other project.

All of that works fairly nicely, but it’s a bit of a maintenance PITA and can be rather error prone. Forget to create the link, and it’s possible everything will still compile, but you’ve got a “bug”.

Well, I just found out that there’s a tool that automates all of this within Visual Studio, provided to us by the patterns & practices team. It’s called the Project Linker: Synchronization Tool. Having just found it, I’ve not yet been able to use the tool “in anger”, but you can be sure I’ll be checking it out real soon.

By the way, if you’ve followed me here from my previous blog on Spaces, welcome to my new home. Hopefully I’ll no longer have to worry about blog spam here! However, being new to this blog, you’ll have to excuse me for a while as I settle in and get things working the way I like.

Update: Near as I can tell, this is where you grab the tool from: http://www.microsoft.com/downloads/details.aspx?FamilyID=387c7a59-b217-4318-ad1b-cbc2ea453f40&displaylang=en#filelist.

Read Full Post »

I’ve Moved

OK, after the rant in my last post, I’ve done it. I’m not going to be posting to this blog anymore. I’m moving over to WordPress at https://digitaltapestry.wordpress.com.

Read Full Post »

Spaces Rant

Windows Live Spaces are driving me nuts. I’m going to be looking for a new home for my blog very soon. I’m that fed up.

I get way too much spam in my comments. Do a Google (Bing) search and you’ll find that this has been a very long standing complaint, and there’s really no excuse for this. The spam I’m getting is very obviously spam, and is guaranteed to be caught by event he lamest of spam filters, but Spaces doesn’t employ any spam filters! Oh, but it gets worse. For much of the lifetime of Spaces there was no way to report spam. The tried to address this, but the result is a pain to the user, and there seems to be no results obtained from reporting the spam. There should be a big SPAM button on every comment when you’re in admin mode. Pressing that button should do numerous things:

  1. It should automatically notify the site administrators as to the wrongful behavior of the user, so an investigation can begin and the user can be banned.
  2. It should delete the comment.
  3. Optionally, it should block the user from ever posting to the blog again (outright banning from all blogs should be done only after investigation by administrators). In this case it should also delete all other comments on the blog left by this user.

Instead, we’re left with having to manually locate a form to fill out with information about the spammer that seems to be ignored, and then manually have to delete every spam comment. Manually deleting those comments is a royal pain. You can’t multi-select, it has to be done one message at a time, and each deletion requires confirmation. In less than a week I’ve received more than 60 spam messages, and deleting all of those is going to waste a lot of my valuable time. What’s worse, it’s all spam that I never should have gotten in the first place, if they’d simply run a spam filter!

Yeah, I’m going to be moving somewhere else. Just got to figure out where.

Sorry for the rant, but I’m in a mood right now!

Read Full Post »