So, I got a comment on the last post about hashes from lambdas (from Andrey Shchekin)... It pointed out the fact that you don't need to use expressions at all... which hilights an observation that I hadn't made myself - such that the lambda parameter names are available in the generated delegate... which of course makes perfect sense!

So given:

Func func = Name => "Value"; 

You can get the lambda parameter "Name" from the function delegate by calling:

func.Method.GetParameters()[0].Name // would return "Name" 

Here's the revised Hash method from Andrey:

public Dictionary Hash(params Func[] args)

where T : class {

    var items = new Dictionary();

    foreach (var func in args) {

        var item = func(null);

        items.Add(func.Method.GetParameters()[0].Name, item);

    } return items;

} 

Very elegant and simple :)

He even did some stats, which I suspect are probably a lot more accurate then my inital observations:

For 10000 consecutive calls:

WithAdd	10.0144ms
WithLambdas	9713.968ms
WithLambdasConstantsOnly	240.3456ms
WithDelegates	30.0432ms

Now what about multiple parameters... so far I can't think of any uses I would have for it... perhaps a 2 level configuration dictionary?

[Test]

public void HashTwoLevelDict()

{

    Dictionary> config = this.Hash

Who knows... I look forward to seeing how Lambdas get used and abused for non-functional programming tasks :)

I've been getting a few questions about different aspects of the container tutorials series I posted a while back - while the series is not finished, neither is it forgotten, I've collated information regarding the series into a topic on my wiki and I'll keep this up to date until I've finished the series off.

I also notice Sam Gentile has posted that he's taking the plunge into learning about castle's Windsor container... good to hear :)

It's been a long time since I've really felt "pleased" by the results of overclocking... probably back in the days of the 300A if truth be told, which is in the long long ago ;o) ... and for the last year I've been mostly using a laptop, and having really kept track of desktop tech.

... So I have to admit to being very pleasantly surprised when I built myself a Core Duo machine (to be used while my Laptop is getting a labotomy) with a bottom of the barrel 4300 processor and then proceeded to overclock it from 1800mhz to 3042mhz ... that's a serious leap in performance :) very pleasing... and I still haven't hit the ceiling which is even more pleasing, I just had to stop fiddling and get on with doing some actual work.

More parts in the container tutorial series are on the way, I've
just been a little busy these last few days.



However I had a discussion with someone about decorators this week
- they eluded to them being too hard to "create" and maintain, and
that opportunities to get them wrong abound (manually writing the
code to call all the members of the inner service) - I was a little
astounded that they didn't know how to do this using
ReSharper.



So heres a quick 1 minute tutorial for those that don't know, first
an interface.

public interface IBondService

{

    void Smoke50Cigarettes();

    void RegisterEnemy(string name);

    void GetOfBed();

    bool GunLoaded();

}

Now let's write the start of our decorator.

public class BondService : IBondService

{

    private readonly IBondService _innerService;
    public BondService(IBondService innerService)

    {

        _innerService = innerService;

    }

}

And then generate the rest... by going to: ReSharper
->Code->Generate...->Delegating Members


Or just type Alt-insert (if your using the default
key bindings) and select "Delegating Members".



At that point select the only option, the inner service.







And then select all the members to delegate for.







And then we get the results... joy

public class BondService : IBondService

{

    private readonly IBondService _innerService;
    public BondService(IBondService innerService)

    {

        _innerService = innerService;

    }
    public void Smoke50Cigarettes()

    {

        _innerService.Smoke50Cigarettes();

    }
    public void RegisterEnemy(string name)

    {

        _innerService.RegisterEnemy(name);

    }
    public void GetOfBed()

    {

        _innerService.GetOfBed();

    }
    public bool GunLoaded()

    {

        return _innerService.GunLoaded();

    }

}

So I quite like Family.Show as an end to end solution of WPF goes... but I think what's been more fascinating is seeing how my (beautiful) Financee is finding it as a working product.

So she's a big genealogy zealot - and for the first time when saying "hey have a look at this" for some random piece of tech I could see here interest was piqued, so we click-once'd it onto her machine and she's been playing around with it for the last day or so - having loaded around 300 people into it so far.

First off the good - it's pretty, and very fluent - you can see immediately who's being edited, current vs. past relationships, dead vs. alive (hollow people are dead... ) And it performs nicely... 200+ vector "people" on screen and the machines not sweating a bit.

Surprisingly it's also pretty quick for data entry, something I had my doubts about when first looking at the application vs. something a little more traditional - after about 5 minutes of experimentation she was an expert.

Second the bugs... well the main one is that certain characters in a name like a double quote causes the "stories" data screen to crash upon saving...  And every now and then it just flakes out completely... I might throw some logging into and see just what's going on, it doesn't even let you get a stack trace *erk*.

Interaction - well here's where she's getting pissed with it and I'll probably need to enhance it a little - and it's all to do with relationships...  there doesn't appear to be any way to establish a relationship between two people once their added to the tree... a pretty big oversight - they expect you to add all relationships by adding a brother/mother/father/sister/spouse/child to the person currently being edited, but that means you cant actually implement something like:

• Joe marries Jane
• Bob marries Martha
• Jane & Bob die
• Joe marries Martha

A big problem during times of war because it was not uncommon for widows to marry the brother of their dead husband.  This seems like a big oversight (though it is just a tech demo).

Interesting though, and this sample is definitely the best WPF app with source code I've had to play/learn from... great stuff Vertigo.