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.

Okay, here are a few weird things that I wish I didn't know about WPF.

• It does some low level cheating all over the place, for fun & profit, put the following like in the main window ctor:
  

  	Debug.Assert(Application.Current.MainWindow != this); 

  Remember that on the CLR, you don't often see other objects referencing before you even started your constructor.
• Then there is this fun puzzle, when I am registering to the Application.Startup event, I am getting inconsistent results with regards to Application.MainWindow being null or not. After a short investigation, I pinned the blame on the async initialization of the windows. But it was a major PITA, to say the least.

So far, I haven't done much with VS 2008. I build Linq for NHibernate, but that was mostly so I could understand how Linq works.

I am now writing a pet project using VS 2008, and I am going to use this post to document the initial impressions.

• No ReSharper for the 3.5 features - EAP is in about a month, YEAH!
• Add reference dialog comes up fast. It comes in a second or so, instead of the 30 - 60 seconds that it used to.
• TestDriven.NET just works.
• I had to use Reflector to figure out how the hell a WPF is starting up (no Main() in sight).
• Go To Reflector (from TestDriven.Net) works.
• The WPF designer is slow.
• No intellisense for Xaml attributes, I think R# has it, though.
• The property pane for WPF is nice.
• I have to type using statements, blah!

What is the result of this piece of code?

application.Startup += delegate
{
    Console.WriteLine("will it");
    application.Startup += delegate
    {
        Console.WriteLine("work?");
    };
};

As usual, I am raffling a Rhino Mocks license among those who will answer correctly.

Interesting way to cache that :-)

Fairly often, we need to do some sort of a transformation between one object to another. It is usually across layers, such as when we want to turn an entity to a DTO (for sending on the wire of for UI purposes).

Here is the overall pattern to solve such a task. I did try to make it into a framework, but even I can't make it more complex than this.

public class OrderToOrderDTO 
{
	public delegate void Transformer(Order o, OrderDTO d);
	
	List<Transformer> transforms = new List<Transformer>()
	{
		(y, z) => z.ID = y.Id, 
		(x,z) => z.CustomerName = x.Name
	};

	public OrderDTO Transform(Order k)
	{
		OrderDTO t = new OrderDTO();
		transforms.ForEach((item) => item(k, t));
		return t;
	}
}

I just run into this problem, and I came up with a different reason than the usual one. C# simply doesn't have the concept of indexed properties. This is not legal C# code:

public static string Items[string something]
{
    get { return something; }
}

I think you can do that with VB.Net, and I am certain that C++ supports it.

The interesting part is that I run into it while building a DSL. The limit of the implementation language has actually limited the DSL itself.

I got some feedback about my previous review, that the PetShop 2.0 was recognized as architecturely unsound, and that I should look at version 3.0 of the code, which is:

Version 3.x of the .NET Pet Shop addresses the valuable feedback given by reviewers of the .NET Pet Shop 2.0 and was created to ensure that the application is aligned with the architecture guideline documents being produced by the Microsoft.

I have to say, it looks like someone told the developers, we need an architecture, go build one. The result is... strange. It make my spider sense tingle. I can't really say that it is wrong, but it makes me uncomfortable.

Take a look at the account class, and how it is structured:

Well, I don't know about you, but that is poor naming convention to start with. And I am seeing here an architecture by rote, if this makes any sort of sense.

Then there are such things as:

Which leads us to this:

The MSG_FAILURE is:

I am sorry, but while there was some effort made here over the previous version, I am not really impressed with it. As I said, the architecture is now probably sound, if suspicious because of lack of character, but the implementation is still not really one that I would call decent. I have to admit about a strong bias here, though. I don't like te naked CLR, but the code has missed a lot of opportunities to avoid unnecessary duplication and work.

I have been also asked what I would consider a good sample application, and I would like to recommend Cuyahoga, as the application that probably models my thinking the best. SubText is also good, but it is more interesting case, because I don't like its reliance on stored procedures. Nevertheless, it is a valid approach, and it certainly serving this blog very well.

Ivan also posted a response to Jeremy's C# vNext features, and he said something that caught my eye:

5. Metaprogramming => no objection here although you can do it now with reflection emit

No, there is a big difference between reflection emit and byte code weaving. Reflection emit is done after compilation is completed, meta programming occurs during compilation. This matters because it means that your code cannot refer to the results of the change being made.

A case in point, I am using IL Weaving to add the Dispose method to a class, but because I am doing it after compilation is completed, I cannot call the Dispose() method on the class, or put it in a using statement, in the same assembly, I would get a compiler error, because the method (and the interface) are not there yet.

Using meta programming, the compiler will know that those now exist, and it can not start using it, because it happened during the compilation process.

The implication of that are pretty significant, if you are talking about what you can and can't do in terms of enriching the language.

Bill Wagner has a proposal about the usage of mixins. He is talking about having a marker interface with minimal methods (or no methods), and then extending that using extension methods. To a point, he is correct, this will give you some sense of what a mixin is. But it is not enough.  

It is not enough because of the following reasons:

• It is not really a cohesive solution. There is no really good way to specify something like SnapshotMixin. You need interface and static class and inherit from the marker interface, etc. Those are... problematic. I want to just be able to say: "also give me the functionality of this class"
• A more important issue is one of state. The examples in Bill's proposal are all stateless methods, but I want to have a stateful mixin. I can think of several hacks around that, but they are hacks, not a proper way to work.