OT2004 : Generic Mechanisms in Software Engingeering

This workshop, hosted by Simon Davies, and chums from Microsoft (with a bit of Bruce Anderson), was a thinking excercise about the pros and cons of some of the language features of C# (and conveniently also Java) including generic types, attributes and dynamic code generation.

We were given some sample scenarios to which we had to contrast the approaches of using these features in isolation and combined together, taking into account ease of development, runtime performance, flexibility, maintainability and simplicity:
* Creating a strongly typed list.
* Serializing objects to XML (a subject I'm familiar with).
* CRUD persistence of domain objects to a database.

This was quite thought provoking. While it was very easy to see the advantages of using generics to implement a strongly typed list, experimenting with all the different approaches was a fun exercise. Code generation may be less simple but offers better runtime performance.

It was fun brainstorming ideas with developers from different backgrounds and seeing which approaches appealed to them.

I was also shown the anonymous delegate feature in the next version of C#. Mmmm closures...

// usage
int totalAge = 0;
peopleFinder.All(delegate(Person person) {
  totalAge += person.Age;
});

// implementation
class PersonFinder {
  
  public delegate PersonDelegate(Person person);
  
  public void All(PersonDelegate delegate) {
    some magic iteration code {
      Person person = ...;
      delegate(person);
    }
  }

}

Now for a staticly typed language, that's a lot cleaner than I was expecting.

This is something I'm really excited about as it's the style of development I use all the time in Java, without all the syntactic cruft of anonymous inner classes. And I'm sure it'll appeal to all the Ruby/Smalltalkers out there.

Something else I learned is that (unlike Java 1.5), generic definitions are available at runtime.

Plenty more info in the C# 2.0 specification.

Comments

exortech

btw, i think that anonymous delegates will be an excellent candidate for future versions of nmock. it will enable us to get rid of having to refer to method names as strings when setting up expectations. we can start treating methods as first-class objects (kinda).

Joe Walnes

Errmm how? We tried this with non-anonymous delegates for C# 1.0 and failed. Could you give an example?

One thing it would do though is supply a much more flexible way of specifiying constriants.

mock.Expect("DoSomething", delegate(params object[] args) { args[0] < 20 && args[1] != "foo"});

exortech

oops... reading through the c# docs i guess i misunderstood the intention of anonymous delegates.

my impression was that i could do something like this:

mock.expect(delegate(Foo), "hello");

void Foo(string message) {
...
}

but i guess you can't. bummer...

Jon Tirsen

Wow! Closures in C# 2.0! And it's really elegant!

Btw, I think it'd be better to do it the Ruby mock objects way, that is allow anything to be executed within the "constraint closure", that way you can reuse all the reporting niceties of Assert (or whatever favourite assertion utility you use). Like this:
mock.Expect("DoSomething", delegate(params object[] args) { Assert.IsTrue(args[0] < 20); Assert.AreEqual("foo", args[1]) };

Name:
Email:
URL: