Daniel has a very interesting post about how mocking can works in C# 3.0 (I don't like the term Linq for Mock, if you haven't noticed).

I wonder if he has used Rhino Mocks, from the description of mock frameworks in the post, it looks like he didn't.

At any rate, the syntax that he has there if quite interesting:

var mock = new Mock<IFoo>();

mock.Expect(x => x.DoInt(It.Is<int>(i => i % 2 == 0))).Returns(1);

The use of lambda as a way to specify expectations is cool, and as a way to specify constraints, flat out amazing.

You can do most of that with Rhino Mocks right now, I feel forced to point out.

IFoo foo = mocks.DynamicMock<IFoo>();
Expect.Call( () => foo.DoInt(0) )
	.Callback( (int i) => i % 2 == 0 )
	.Return(1);

We even have an Is.Matching constraint, that we can use instead:

Expect.Call( () => foo.DoInt(0) )
	.Constraints( Is.Matching<int>( i => i % 2 == 0) )
	.Return(1);

I guess we will just need to see what kind of cool stuff we still have in store for it.

Great job, Daniel.

I suggest that you would check this out. The Quick Start gives few more examples, and it is looking really nice.

By the way, for the horde of people who would like to "port" those examples to Rhino Mocks, we have a wiki... :-) 

I got quite a few requests for more information on this, beyond the short documentation in this post. This is not something that I was very happy with because I feel that Rhino Igloo represents a compromise that I am not very happy with. Consider this the product of a developer longing for MonoRail while having to deal with WebForms world.

I am not making excuses for this project, it is meant to serve a very specific goal, and it has done that very successfully.It is also extremely opinionated and may not fit what you want to do.

• Length: 57 minutes
• Download size: 79 MB
• Code starts at: 11:14

You can download the screen cast here. There is a secret message there, let us see if you can spot it.

Update: looks like the file I uploaded is corrupted, I'll upload a new one soon, in the meantime, I removed it from the download page.

Update 2: Uploaded a good version, it is available now.

There is a discussion in the alt.net mailing list right now about how far you can and should trust your compiler. I thinks that this is interesting, because this piece of code of mine is on its way to production:

public Guid Create<T>(T newEntity)
{
	using (CrmService svc = GetCrmService())
	{
		object cheatCompiler = newEntity;
		Guid guid = svc.Create((BusinessEntity) cheatCompiler);
		return guid;
	}
}

This is part an implementation of an interface in an assembly that cannot reference BusinessEntity.

I am feeling good with this.

IFooFactoryFactoryFactoryFactory vs. Factory<Factory<Factory<Factory<Factory<IFooFactory>>>>>

Discuss...

When you are not sure how to do something in Boo, try doing it like you would with C# (with the obvious syntax changes), in most cases, it would work. It may not be the best way to do something, however.

Keep this a secret, I may get thrown out of the Boo Associated Hackers community if that would happen, and where I would be without my BAH! membership?

I really like the CLR. It is a great platform, it has a rich set of libraries, it has a lot of power and flexibility, and it was designed with multi language support in mind, which means that what you can do on the CLR vs. what you can do in your language are two different things.

It is just too bad that the default CLR language is C#. Now, that probably raised a few brows, and definitely some hackles. C# is a great language, I can hear you saying. Well, yes, sort of. If you thinks that holding the compiler’s hands is a useful thing to do. Leaving aside the ability to extend the compiler, Boo has the following to offer us:

Syntactic sugar for common programming patterns - List, hash and array literals, object initialization, string formatting and regular expression matching are all first class concepts in Boo, with direct support for all of them in a natural manner.

Automatic Variable Declaration together with Automatic type inference – the compiler takes care of things for you, instead of having to type the same thing over and over and over again. Some would say that this is bad, for them I would reply that they should try it first. It works.
Take a look at this:

def random():
	return 4 # selected by dice roll, guaranteed to be random
val = random() 

Is there are reason that I would need to specify the type over and over again? The compiler can figure it out for itself and not bother you with it. If you want to get a compiler error, you can:

val as string = random() # will error about type mismatch 

Automatic type casting – don’t make me explicitly say it, figure it out for me. I’ll have unit tests to check to cover me.

Duck typing – Boo is a strongly typed language, but you can ask the compiler to relax those constraints at certain scenarios. It makes some things much more natural, especially since you have a way to get into this infrastructure and decide what to do at runtime.
If we will take a simple example, let us look at the XmlObject and what we can do with it:

person = XmlObject(xmlDocument)
print person.FirstName
print person.LastName 

What we just did was resolve, at runtime, that we were asked to get the value of a property called “FirstName”, and we did. This is a trivial piece of code to implement.

Just those benefits present a significant improvement in the language experience, and we haven’t even touched the extensible compiler yet.

So, what is this Boo language anyway? I am talking about it fairly often, but I never explained, and I am going to assume that people aren't following links :-)

Boo is an object oriented, statically typed language for the common language runtime with a Python inspired syntax and focused on language and compiler extensibility.

Boo is an Open Source project, released under the BSD license. This means that you are free to take, modify and use the language and its products in any way you want, without any limitation[1]

. Rodrigo B. de Oliveira started the project, and since then grown in popularity. The project is active and continually evolving. At the time of the writing, the released version of Boo is 0.8.

However, Boo seems to be following the trend of many open source projects, in that that it is not really rushing toward 1.0 release. Boo has been around for a number of years, and I have been using it for production for the last two years.

Production, in this case, means systems that move money around with my neck on the line. I have a high degree of trust in it, obviously.

Beyond being a really malleable language, suitable for DSL. Boo is also a nice language to work with for day-to-day tasks. The SharpDevelop IDE project has support for Boo, so you get the usual benefits. There is an ongoing project to support Boo in Visual Studio, and I have an active interest in seeing support for that being established. I don't much care for which IDE, but I want a standard, checklist driven way of getting a language running.

Here is a secret, I tend to think and write in Boo, translating down to C# because I have to. Boo is a far more flexible language, and the ability to reprogram the compiler makes tedious tasks in other languages an amusing challenge. Those same tedious problems are usually overcome, to some degree, by throwing code generation at the problem until it goes away.

In Boo, we would usually tell the compiler how we want to handle this, and let the compiler take over from there. This is similar to code generation, except that this is done at the compiler level, which means that we have far more knowledge about what is going on.

For example, let us say that we want to implement the singleton pattern. We need to do quite a bit of work to make it happen. Ensure that creating the singleton is thread safe, lazy initialization, make all the constructors private, ensure that serializable singleton remain singleton through serialization/deserialization, create static Instance property, have no static members on the singleton class.

To do this in most language we would have to follow an implementation pattern and write fairly repetitive code. In Boo, we can capture this usage pattern in an AstAttribute (more on that later) that will do all of that for us, at the cost of a single attribute declaration.

Similar capabilities allow correct usage of disposable, observable, and more advance techniques such as aspect oriented programming.

Some of the capabilities that Boo has can be had using IL Weaving tools such as PostSharp. The problem with those is that using them is something that happens after compilation. As a simple example, you would not be able to create a singleton in this manner, because you would not be able to generate the Instance property at the appropriate time.

Assuming that you want to use the singleton in the same assembly as it was defined, you will not be able to reference the Instance property, it will not exist until the post compile step has run. Boo, however, does this at compile time, so by the time the compiler get to the point where it is resolving the property, it has already been added.

In short, I really like the language and what it allows me to do.

[1] Well, if you are interested in creating a new language called Ba, you probably would want to make it clear where the project ancestry came from…

I just found about this, a hack that let me actually get useful functionality from the useless key directly in the middle of my otherwise wonderful keyboard.

Two posts and a discussion yesterday has finally made it clear what my stance in regards to extensibility is. Extensibility is well and good, but if I need to extend a product from the get-go, just to get the basic functionality going, then this product blew it.

The discussion that I had was about SSIS and the need to create a DateParserComponent. Basically, a wrapper around DateTime.ParseExact(). I don't mind the work in creating it, but it is very telling that this is something that you would need. The posts that help cement this thinking were Phil Haack about Convection Controller and Ivan's Filters implementation for the MS MVC framework.

Let us start by saying that neither posts has code that I can take to production, and that is explicitly state in the posts. Demo code is demo code, after all.

Nevertheless, I am going to talk about this demo code, and its implications. Phil has posted this Convention Controller as a way to show how easy it is to extend the MS MVC framework. The problem with that this is showing how to extend the MS MVC framework for demos. The code required to make this run for production is far more complex*.

Production code has to be reliable, performant, stable, etc. A lot of effort goes into taking a piece of code from the proof of concept stage to the ready to production stage.

I believe that extensibility is extremely important. But that to answer of "you can extend the product" for any core scenario is nothing but blame shifting. I mean, Date Parsing in an ETL tool? Can you really consider that as a noncore scenario?

Now, in order to avoid the hordes of people that this will offend. I want to make one thing clear, convention controller is not a core scenario for the MS MVC framework. That is a by design choice of them that I disagree with, but that is the way it is.

We now begin to see a lot of the MonoRail stuff appearing on the MS MVC side, Rescues, Filters, etc. I hope that most of them would end up with the core product, but MS has stated the MonoRail feature parity is not a goal.

Just keep this in mind the next time that you are going to say "it is extensible, do this", you really ought to consider whatever this is an answer that is driven by the product's core scenarios vs. moving the work that should be yours to someone else's hands.

* This post is not about the convention controller, but to foretell the usual nitpickers, reflection is slow. Using un-cached reflection in a hotspot is a bad idea, even cached reflection is inappropriate at times.