# Thursday, July 26, 2007

I came across http://www.codeplex.com/csparser today. This parser takes C# source code and produces in memory object tree representing the code. This object tree can be modified and the resulting source code extracted back out as a string.

I have been thinking about ways to remove the mindless plumbing code I have to write when implementing a Model-View-Presenter architectural system. For example, I define an interface for my Model. I then make a Model class that implements the Model interface. The slow bit here is implementing all the properties with fields, defining events and the OnSomeEventHappened(Args) methods to safely raise them.

Whilst there are tools that will probably do this plumbing for me, they have one flaw. I don't want to even read, let alone write, that boiler-plate code! It does not help me understand what it going on. The interface contains all the important details. I basically want the compiler to generate it for me.

C# has no syntactic macro system (unlike Boo and Nemerle) so I'm stuck with my current XML/XSLT based code generator. Whilst this is usable, it really means I'm no longer coding in C#, but rather long-winded XML. The context switch there is a bit annoying.

With the CS Parser I will be able to the following:
Write a Visual Studio Custom Tool (like my XML/XSLT code generator) that takes C# code file of an interface and generates an implementing class. This is done by parsing the interface definition, then looping through members and creating a new class definition accordingly.
If the class already partially exists I can allow the user to type specific members they need to implement in a non-standard way and not generate these automatically.
The output of the Custom Tool (new C# code) is then compiled automatically as part of the Visual Studio build process.

For example:

public interface IModel
{
  int Amount { get; set; }
  event EventHandler AmountChanged;
  void Load();
}

Generates into:

public partial class Model : IModel
{
  int _amount;
  public int Amount
  {
    get { return _amount; }
    set
    {
      _amount = value;
      OnAmountChanged();
    }
  }
  public event EventHandler AmountChanged;
  protected virtual void OnAmountChanged(EventArgs e)
  {
    EventHandler handler = AmountChanged;
    if (handler != null)
       handler(this, e);
  }
}

Leaving the developer just to write the Load method.

I'm wondering about generalising this a bit. Using magic attributes that are picked up by a tool (much like syntactic macro attributes in Nemerle) to invoke specific actions.

[AutoImplement(IModel)]
public class Model : IModel
{
   public void Load() { ... }
}

Fun times ahead!!

Thursday, July 26, 2007 5:47:58 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [1]  | 
# Monday, July 16, 2007

Sorry, this not technically "about code", but I'm moving to Bristol on the 27th July. I'm moving into a new flat and am looking forward to working and playing in Bristol!

Hopefully I'll get lots of work done ;)

Monday, July 16, 2007 7:53:33 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, July 13, 2007

Erik Meijer is involved in some very interesting research at Microsoft Research. This latest video on Channel 9 introduces the work his team are doing to make writing an application a single concept and then splitting it over tiers as required.

He talks about using a refactoring to split a class out into different parts for required tiers. For example, a model running on a client needs to talk to a database at some point. That part of the code needs to be running in a context that can access the database i.e. the server. The refactoring generates a service class that contains the database access code, and the client class is updated to call the service.

Apparently they are working to make this declarative. I imagine this looking something like:

[RunAtServer] void MyMethod(int id) 
{
  var people = from p in DB.GetPeople() where p.ID = id select p.Name;
  // etc...
}

Of course, the "macro" siren went off in my head. I could probably do something like this today in Boo or Nemerle. For making close-coupled systems (where data types are shared between tiers) this could be amazing. All we need is an assembly level macro that scans class for certain attributes and auto generates the required services, proxies and proxy calls.

When you have .NET running everywhere (i.e. Silverlight in the browser) this kind of magic becomes more of a reality. I'm also very interested to see the MSIL to JavaScript compiler Erik is working on.

Friday, July 13, 2007 11:22:55 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Sunday, July 08, 2007

David Hayen talks about the problem of using code generation at a large scale within software projects. The first use gives a lovely RAD hit, but over time you get more constrained and limited by the generated code. I always found this problem using any kind of data-n-drop data binding (although .NET 2.0 windows forms data binding seems almost flexible enough).

It is hard to get large scale code generation perfect - almost impossible in reality. I find using code generation at a smaller scale to actually raise the level of abstraction in code more useful. Languages such as Boo and Ruby have great syntax for defining mini domain specific languages to raise abstraction levels. Syntactic macros in Nemerle and Lisp are true compile-time code generators. The key to these methods is that the programmer has not lost the expressivity his language gives him. If a certain macro is not really fitting, you can always write out the code long-hand and refactor later if necessary.

Large scale code generation assumes software is smooth and regular. In the real-world we have to deal with special cases and, worse, changing requirements. Trying to make a code generation tool fit all of these requires it to be as expressive as a real programming language! Only now we are buried in stacks of XML config files and templates.

One area I do see a benefit for these quick-n-dirty code generators is in prototyping. You want to get something half-real in front of customers quickly to gather feedback. However, never be precious about your code. The best writing is re-writing! A lot of software hangs around for a lot longer than we expect, or even hope. It is probably best to make it as maintainable as humanly possible.

The fact that a magic tool generated thousands of lines of code for you doesn't stop them for existing. The more code that exists, more chance there is for something to be wrong. If your chosen programming language requires you to write reams of code to express something that you can conceptualise more simply, then I'm sorry you need a better language.

Sunday, July 08, 2007 1:03:08 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, July 06, 2007

I have attached the Boo code containing the Rhino Mocks DSL I'm currently working on. This is very much a work in progress release, just to get it out there. Please have a play and tell me what you think. Happy Mocking!

Dsl.boo (3.4 KB)

To use the DSL, add the following in your code to import the static methods into scope.

import Rhino.Mocks.Dsl

Friday, July 06, 2007 1:19:48 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  | 
# Wednesday, July 04, 2007

I thought some more about the syntax of my Rhino Mock DSL. It can feel unnatural putting all the mock expectation code before the call to the object being tested. I came up with this working prototype instead:

[Test]
def Get_data_objects_for_nonexistent_company_throws():
    with_mocks:
        database = mocks.CreateMock[of IDatabase]()
        userProvider = StubUserProvider("andrew", "bad corp")
        userProvider.MakeCurrent()

        execute:
            uds = UserDataService(database, userProvider)
            expect_throw FaultException[of GetDataObjectsFault]:
                uds.GetDataObjects()
            assert thrown_exception.Detail.Type.Equals(GetDataObjectsFaultType.InvalidCompany)

        assuming:
            database.GetUserID("andrew", "bad corp")
            returned 1
        assuming:
            database.GetCompanyID("bad corp")
            returned 0 # returning 0 from database implies nonexistent company.

The with_mocks method sets up the mock repository and a Store object. The execute and assumption methods then put their blocks into the Store. At the end of with_mocks I iterate through assumptions calling each to set up the Rhino Mock expectations. Following that is: mocks.ReplayAll(), call to the "execute" block, then mocks.VerifyAll().

The other clever bit in there is the expect_throw method. This runs the block inside a try...except and fails if no exception (or wrong exception type) is thrown. It puts the exception object into field that is readable using thrown_exception. This means we can then test assertions about the exception contents. I had to cheat a bit and declare thrown_exception as "duck" in Boo i.e. it is late bound. This is so we can access members on the actual object despite not really knowing about it at compile time.

I like the readability now. The outline is:

  • Initialize mocks and data objects
  • Call the object being tested
  • Assert about the result
  • State the assumptions about how dependencies are used

The key bit, I feel, is that the call to the object being tested is not buried down at the bottom of the method.

How does everyone else feel about this modified approach?

Wednesday, July 04, 2007 11:41:55 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, July 03, 2007

Why can't Microsoft do more to support external projects like Boo and Nemerle? It drives me insane seeing all the love Python and Ruby are getting from Microsoft, when there are languages out there that embraced the CLR from day one being ignored!

To be honest, by "love" I mean IDE love. Nemerle is a great language - light years ahead of C#. The same goes for Boo. But the tool support for these languages in poor. The Nemerle VSIP project barely usable for any serious work and for Boo the only real option is SharpDevelop.

I confess, I am a total Visual Studio junkie. I need my tools. Using emacs and cmd prompt for some project with hundreds of source, resource and data files is stupid. You shall take intellisense from my cold dead hands!

The problem it seems that developing a reliable, complete, VS integration package is very hard. Microsoft: please reach out to these pioneering developers and offer them what ever they need to get their awesome languages in Visual Studio. Just do it. In fact, go one better and release Boo Express and Nemerle Express for free! The .NET world will thank you.

Reading this kind of shit makes me so very sad.

Tuesday, July 03, 2007 9:40:46 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [1]  | 

I recently learnt that Boo now supports a DSL-friendly syntax. A while back I created (and almost finished!) a set of syntactic macros in Boo to make using Rhino Mocks much more natural. Creating macros can be hard work though and gets pretty hacky in places.

The new DSL-friendly syntax in Boo means I can achieve 80% of the same easy-reading code, but using only methods and blocks!

In about 10 minutes I whipped up this:

namespace ConsoleDemo

import System
import Rhino.Mocks
import Rhino.Mocks.BooDsl.MockDsl

interface IModel:
    def CalculateScore(input as int) as int
interface IView:
    def DisplayScore(score as int)
interface IPresenter:
    def Init()

class Presenter(IPresenter):
    _model as IModel
    _view as IView
    def constructor(model as IModel, view as IView):
        _model = model
        _view = view
    def Init():
        score = _model.CalculateScore(0)
        _view.DisplayScore(score)

def Test_presenter_init():
    with_mocks:
        // Create mocks of the dependencies
        model = Mocks.CreateMock of IModel()
        view = Mocks.CreateMock of IView()
        // Create the object we are testing
        presenter = Presenter(model, view)
        // Record what we expect the presenter to
        // do with its dependencies.
        record:
            expect:
                model.CalculateScore(0)
                // Set the return value for the
                // previous mock call.
                mock_return 42
            expect:
                view.DisplayScore(42)
        // Now tell the presenter to do its stuff,
        // so we can verify it behaves correctly.
        verify:
            presenter.Init()
print "testing..."
Test_presenter_init()
print "all good!"
print "Press any key to continue . . . "
Console.ReadKey(true)

The import of "Rhino.Mocks.BooDsl.MockDsl" brings some new methods into scope. with_mocks initializes a MockRepository. "Mocks" is actually a property referencing that repository, so we can call CreateMock, etc, on it. The record and verify methods make use of the Mocks.Record() and Mocks.Playback() methods. I prefer using "verify" to "playback". The "expect" method runs the code in its block, usually that invokes some mock method. It then calls "LastCall.Repeat.Once()" to set up the expectation. The "mock_return" method calls "LastCall.Return(value)" to set up the return value for the last mock call.

This is all a bit messy for now I know. I have just being throwing code down into this prototype to get a feel for what is possible. I reckon this could be really useful for people using Rhino Mocks.

If you like what you've seen or have any ideas let me know.

The DSL methods are as follows:
I am aware of more than one glaring danger in the code(!) but it does show what can be done.

namespace Rhino.Mocks.BooDsl

import System
import Rhino.Mocks

callable Block()

static class MockDsl:

    private static _instance as MockDslImpl
    static def with_mocks(b as Block):
        _instance = MockDslImpl()
        b()
        _instance = null
    static def record(b as Block):
        assert _instance != null
        _instance.Record(b)
    static def verify(b as Block):
        assert _instance != null
        _instance.Verify(b)
    static def expect(b as Block):
        assert _instance != null
        _instance.Expect(b)
    static def mock_return(value as object):
        assert _instance != null
        _instance.MockReturn(value)
    static Mocks as MockRepository:
        get:
            assert _instance != null
            return _instance.Mocks

    private class MockDslImpl:
        mocks as MockRepository
        def constructor():
            mocks = MockRepository()
        public Mocks as MockRepository:
            get:
                return mocks
        public def Record(b as Block):
            using mocks.Record():
                b()
        public def Verify(b as Block):
            using mocks.Playback():
                b()
        public def Expect(b as Block):
            b()
            LastCall.Repeat.Once()
        public def MockReturn(value as object):
            LastCall.Return(value)

Tuesday, July 03, 2007 12:03:52 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, June 27, 2007

I got my University of Warwick Computer Science BSc result today: First Class!

Whilst this has no affect on my plan to start my own business, it's still nice to know that I'm not that awful at computer science. :)

Right then, on with the code monkeying for now.

Wednesday, June 27, 2007 11:29:54 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, June 18, 2007

Using Silverlight 1.1 means I am able to write .NET code that runs in the web browser. This should make it very easy to implement a clean model-view-presenter (MVP) architecture. I am envisaging a model that acts as a web-service proxy to get data and perform actions on the server. The view would thinly wrap the XAML UI. The presenter would handle all the interactions between the other two. This makes for very unit-testable code.

The one thing I'm not sure about is what level of granularity to use regards presenters and views. In XAML it is possible to define amazing interfaces that have animations and transitions between states. Should these different UI states have distinct view/presenter objects? Would it make sense to have a single XAML canvas that implements a number of different View (OOP) interfaces?

Does anyone have good resources dealing with switching views?

Monday, June 18, 2007 4:04:07 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  |