A few days ago I was listening to a recording of a design discussion, and I was at two minds about what was going on in my mind when I said some of the things that I said. I found myself in the odd position of both remembering my reasoning and listening to them as an outsider. It gave me some insight to the way I think. It is not really an analytical process.

There is a lot based on the taste of the idea. I am sorry, I am not sure how to express it in any other way. I decide on the idea/design based on how it feel. There was a lot of that in the discussion, for instance. I can usually explain my initial response when I give it some thought, luckily.

At one point there were about two minutes of failed design attempts, we can do X and then... hm, not that is too complex, so we will do Y which would... no, that doesn't handle the Foo requirement, etc.

It is partly preference, partly experience and partly the appliance of good habits learned from painful experiments.

Interesting experience...

Not, I am not particulary hungry at the moment, despite what this image may suggest.

Let us assume that I am hungry, and I would like some sort of a Vegetable to eat. Now, I know that I would really like to eat a carrot.

Problem.

I don't want to try all the possibilities in the kitchen. That would be real horror. But do I have any other choice? Assume that I have the time to do whatever I want, how would you handle the question of "give me something like carrot".

Please remember that simplicity is a value. And yes, I do have an idea about this.

I posted yesterday about building a rule engine using a DSL. After I wrote that, I tried to think about what style it was. That made me realize that I had no clear distinction between imperative and declarative DSL. At least not a coherent, internally consistent one.

I asked the Alt.net mailing list, and a lively discussion enthused. Contrary to my opinion, a lot of people disagreed with my opinion that this is a declarative style DSL:

when User.IsPreferred and Order.TotalCost > 1000:
    addDiscountPrecentage  5
     applyFreeShipping
when not User.IsPreferred and Order.TotalCost > 1000:
suggestUpgradeToPreferred
     applyFreeShipping
when User.IsNotPreferred and Order.TotalCost > 500:
     applyFreeShipping

It looks too much like code apperantely. After some debate, we now have the following candidates for declarative DSL:

From Chad:

about User
       when Preferred and OrderTotal > 1000:
               Discount is 0.05
               And Shipping is FREE;
       when not Preferred and OrderTotal > 1000:
               Upgrade Suggested
               And Shipping is FREE;
       when not Preferred and OrderTotal > 500:
               Shipping is FREE;

Based on Berry's ideas:

applyDiscount 5.precent:
    when User.IsPreferred and Order.TotalCost > 1000
suggestPreferred:
     when not User.IsPreferred and Order.TotalCost > 1000
freeShipping:
     when Order.TotalCost > 500

The really interesting thing to me, so far, is that they are all functionality equivalents. From the point of view of the implementer, there isn't much difference at all betwee them.

My own, loosely defined and likely wrong definition was based on what the DSL actually did. If the DSL performed all the work internally, I would call it imperative. If the DSL performed some work that produced an object graph, which another part of the system would tehn consume, I would call it declarative.

Thoughts?

After I got some input from Scott Allen about my Rule Engine post, I took a look at PolicyActivity.

Take a look at the image, my commentary is below it:

Can someone please explain me who thought about this idea? When you get something like that, how are you supposed to actually look at this and figure out what is going on? You have no way to look at it and get an idea about what is going on in there. You have to go and look at those sub rules one by one.

For that matter, take a look at the text boxes here. You want me to write code there? There is actually intellisense on those text boxes, which scares me to no end.

How am I supposed to be able to get an idea on what is going on here? An overall view, not just inspecting a single leaf of grass at a time.

How am I to do code review on that? For that matter, how am I going to use source control with that. The answer, sadly, is again, binary source control. No diffs for you, nasty spoiled code driven developer. Take a look at this snippet.

<Rule.Condition>
	<RuleExpressionCondition Name="{p3:Null}">
		<RuleExpressionCondition.Expression>
			<ns0:CodeBinaryOperatorExpression Operator="ValueEquality">
				<ns0:CodeBinaryOperatorExpression.Left>
					<ns0:CodePrimitiveExpression>
						<ns0:CodePrimitiveExpression.Value>
							<ns1:Int32 >1</ns1:Int32>
						</ns0:CodePrimitiveExpression.Value>
					</ns0:CodePrimitiveExpression>
				</ns0:CodeBinaryOperatorExpression.Left>
				<ns0:CodeBinaryOperatorExpression.Right>
					<ns0:CodePrimitiveExpression>
						<ns0:CodePrimitiveExpression.Value>
							<ns1:Int32>2</ns1:Int32>
						</ns0:CodePrimitiveExpression.Value>
					</ns0:CodePrimitiveExpression>
				</ns0:CodeBinaryOperatorExpression.Right>
			</ns0:CodeBinaryOperatorExpression>
		</RuleExpressionCondition.Expression>
	</RuleExpressionCondition>
</Rule.Condition>

I actually had to cut some name space definitions from there, just to make it fit the screen.

Now, please guess what this translate to. Imagine a slightly more complex rule, and then try to do a diff on the changes when someone modify it.

I am waiting to be educated how this is a good thing.

Over in the alt.net mailing list, Charlie Poole has said that he thinks that the Playback() method for Rhino Mocks would be better named Monitor().

Without thinking about it, I sent this reply:

public class CharliePreferences
{
     public static IDisposable Monitor(this MockRepository mocks)
     {
              return mocks.Playback();
     }
}

After I sent it, I started thinking about the implications. Both for legacy code and for preferences. I am not sure whatever this is a good approach is a good way to go. Thoughts?

As I continue to explore what we can do with DSL, I am getting more and more excited. Let us take a look at the following syntax:

when User.IsPreferred and Order.TotalCost > 1000:
    addDiscountPrecentage  5
    applyFreeShipping
when not User.IsPreferred and Order.TotalCost > 1000:
    suggestUpgradeToPreferred 
    applyFreeShipping
when User.IsNotPreferred and Order.TotalCost > 500:
    applyFreeShipping

The backend for that is a simple 68 lines class. Again, we had to extend the language to support the when keyword, but that is all we really had to do.

I tried to build the same using Windows Workflow, but I gave up after a few minutes. It was too much clicking, and not enough results.

It should look something like the image to the left, I assume.

From the perspective of maintainability and actually being able to look at what is going on, I know what I would like to have.

At any rate, you can get the backend here, and get the unit tests here. Both are part of the test suites of the Rhino DSL project.

To be frank, I can't believe how easy this stuff is.

.

I went to sleep with the computer still playing. A few hours later, I woke up from a highly disturbing dream that I refuse to disclose, to find out that for the last hour or so, I have been hearing a WPF conversation. I'll leave any association between these two facts to the reader. But to top that, I found out that on VS 2005, I don't have ReSharper installed.

I had to run around like a headless chicken for a while, just to get to grips with that. Then I installed it again (removed previous version to install the EAP on VS 2008). I am feeling much better now, honestly. Now if I could only forget that dream...

Taking advantage of a loophole in the export laws and some creative marketing, I am pretty sure that a startup to sell USB Nuclear Powered Rocket Launchers to petty tyrants is the next big thing.*

Wish me well, I now need to learn how to say I come in peace in Persian.

* This is a three level joke, if you don't get, don't worry, it is not intended to you.

What do you think about this code?

IoC.Container.Kernel.AddComponentInstance<IFoo>(this);
IBar context = IoC.Resolve<IBar>();//needs IFoo

For some reason it looks really funny to me.

More seriously, this is a good way to involve components that you cannot control in the container.

I just found myself writing this:

[Test]
public void When_resolving_using_framework_element_will_create_layout_using_resolver()
{
}

The code that I want to test looks something like this:

public void Register(FrameworkElement frameworkElement)
{
	Register(layoutDeocratorResolver.GetLayoutDecoratorFor(frameworkElement));
}

public void Register(ILayout layout)
{
	if (layouts.ContainsKey(layout.Name))
		throw new DuplicateLayoutException("Layout names must be unique. A layout named '" + 
                                      layout.Name + "' already exists.");
	layouts.Add(layout.Name, layout);
}

The problem that I have here is that it looks like I am trying to specify the mechanics of the code under test, and that is a big mistake. I really should not care how it is doing it. I should care about the results. Therefor, I decided to change the test to:

[Test]
public void When_resolving_using_framework_element_will_add_layout_decorator_for_that_element()
{
}

Now what I am testing is behavior, not mechanics.

Tests that validate the mechanics of the code are brittle, and end up as testing shackles.