Krzysztof Koźmic's blog

Castle Dynamic Proxy tutorial part XV: Patterns and Antipatterns

2009-10-30T04:20:23-07:00

We’ve covered almost all of Dynamic Proxy. If you followed along through this series, you now know 95% of Dynamic Proxy 2.1 features that get used 99,9% of the time. Now is the time to wrap up, and with that we’ll review some of the most common pitfalls that you may encounter when developing code on top of Dynamic Proxy.

Leaking this

Consider this simple interface/class pair

public interface IFoo

    IFoo Bar();

public class Foo : IFoo

    public IFoo Bar()

        return this;

Now, let’s say we create a proxy for IFoo with target and use it like this:

var foo = GetFoo(); // returns proxy

var bar = foo.Bar();

bar.Bar();

Can you see the bug here? The second call is performed not on a proxy but on a target object itself! Our proxy is leaking its target.

This issue obviously does not affect class proxies (since in that case proxy and target are the same object). Why does not Dynamic Proxy handle this scenario on its own? Because there’s no general easy way to handle this. The example I showed is the most trivial one, but proxied object can leak this in a myriad of different ways. It can leak it as a property of returned object, it can leak it as sender argument of raised event, it can assign this to some global variable, it can pass itself to a method on one of its own arguments etc. Dynamic Proxy can’t predict any of these, nor should it.

In some of these cases there is often not much you can do about it, and its good to know that problem like this exist, and understand its consequences. In other cases though, fixing the issue is very simple indeed.

public class LeakingThisInterceptor:IInterceptor

    public void Intercept(IInvocation invocation)

        invocation.Proceed();

        if(invocation.ReturnValue == invocation.InvocationTarget)

            invocation.ReturnValue = invocation.Proxy;

You add an interceptor (put it as last one in the interceptors pipeline), that switches the leaking target back to proxy instance. It’s as simple as that. Notice that this interceptor is targeted specifically at the scenario from our example above (target leaking via return value). For each case you will need a dedicated interceptor.

Override equality

One of the most common mistakes when it comes to Dynamic Proxy is not overriding Equals/GetHashCode methods on proxy generation hooks and interceptor selectors, which means you’re giving up caching and that in turn coupled with bugs in BCL means performance hit (plus increased memory consumption).

Solution is very simple, and there’s no exceptions to this rule – always override Equals/GetHashCode methods on all your classes implementing either IProxyGenerationHook or IInterceptorSelector.

Make your Proxy Generation Hooks purely functional

Pure function, is a function that for given set of inputs always returns the same output. In case of proxy generation hook, it means that two equal (as specified by overriden Equals/GetHashCode methods) proxy generation hooks will for given type to proxy return the same values from their methods, and when asked again about the same type will again return the same values/throw the same exceptions.

This is a major assumption that Dynamic Proxy makes, and that’s what makes the caching mechanism work. If proxy generation hook is equal to the one already used to generate a proxy type, Dynamic Proxy will assume it would return the same values as the other one, which would result in identical proxy type, so it cuts through the generation process and returns the existing proxy type.

Make your supporting classes serializable

If you’re going to be serializing your proxies, you should make all the classes that go with it serializable. That includes proxy generation hooks, interceptors and interceptor selectors. Otherwise you will get an exception when trying to serialize your proxies. It is not mandatory, but I find it useful. Notice that you will need this also when persisting your proxy assembly to disk.

Use ProxyGenerationHooks and InterceptorSelectors for fine grained control

Do your interceptor’s methods look like this?

public void Intercept(IInvocation invocation)

    if(invocation.TargetType!=typeof(Foo))

        invocation.Proceed();

        return;

    if(invocation.Method.Name!="Bar")

        invocation.Proceed();

        return;

    if(invocation.Method.GetParameters().Length!=3)

        invocation.Proceed();

        return;

    DoSomeActualWork(invocation);

If they do this often means you’re doing something wrong. Move the decisions to proxy generation hook and interceptor selector

Do I ever want to intercept this method? If the answer is no, use proxy generation hook to filter it out of methods to proxy.

Notice that due to bug in Dynamic Proxy 2.1, if you choose not to proxy method on interface proxy, you will get an exception. Workaround for this is to say you want to intercept the method, and then use interceptor selector to return no interceptors for the method. This bug is fixed in Dynamic Proxy 2.2

If I do want to intercept this method, which interceptors do I want to use? Do I need all of them? Do I need just a single one? Use interceptor selector to control this.

On the other hand, remember that as every feature this one is also a double edged sword. Too liberal use of proxy generation hooks and interceptor selectors may greatly decrease efficiency of proxy type caching, which may hurt your performance. As always think how much control you need and what the implications on caching will be. Sometimes single if on top of your interceptor is lesser evil than increasing number of proxies required tenfold. As always – use the profiler in scenarios that mimic your production scenarios as closely as possible to check which option is the best for you.

SRP applies to interceptors

SRP stands for Single Responsibility Principle, which means that a class should do just one thing. Many people seem to forget about it when it comes to interceptors. They create one monstrous interceptor class that tries to do all the things they need from Dynamic Proxy – logging, security checking, parameter verification, augmenting target objects with behavior and many more.

Remember that Dynamic Proxy lets you have many interceptors per method call. Use this ability to split behavior between interceptors. You may end up with some general purpose interceptors for things like logging that you use for each intercepted method on each class. As long as all it does is logging – that’s ok.

You may end up with some interceptors that are used for methods on just some classes, like classes inheriting from common base class. As long as these interceptors do just one thing – that’s fine.

You may end up with some interceptors that exist solely for the purpose of intercepting just a single method on specific class or interface. That also is fine. Use interceptor selectors to match interceptors to their respective targets, and don’t be afraid to have multiple interceptors per method.

Technorati Tags: Dynamic Proxy,Castle

Castle Windsor forwarded types and proxies

2009-10-22T14:25:22-07:00

Castle Windsor allows you to use single component for multiple services, which is called Forwarded Types.

Forwarded Types

In other words, you can tell Windsor – when IFoo is requested use FooBar as implementation, and when Bar is requested also use FooBar (when using default lifestyle of singleton you’ll get the same instance).

Here’s some code:

var container = new WindsorContainer();

container.Register(Component.For<Bar>().Forward<IFoo>()

                       .ImplementedBy<FooBar>());

var foo = container.Resolve<IFoo>();

var bar = container.Resolve<Bar>();

Debug.Assert(foo == bar);

foo.DoFoo();

bar.DoBar();

Console.ReadKey(true);

Proxies

What if you want to use proxies for that component though?

var container = new WindsorContainer();

container.Register(Component.For<IInterceptor>()

                       .Named("interceptor")

                       .ImplementedBy<FooBarInterceptor>(),

                   Component.For<Bar>().Forward<IFoo>()

                       .ImplementedBy<FooBar>()

                       .Interceptors(new InterceptorReference("interceptor")).Anywhere);

var foo = container.Resolve<IFoo>();

var bar = container.Resolve<Bar>();

Debug.Assert(foo == bar);

foo.DoFoo();

bar.DoBar();

Console.ReadKey(true);

Now, what happens next depends on how you implemented the interface IFoo on class FooBar. Say this is FooBar:

public class FooBar : Bar, IFoo

    public void DoFoo()

        Console.WriteLine("DoFoo");

    public override void DoBar()

        Console.WriteLine("DoBar");

Notice that DoFoo is non-virtual. In this case, here’s what we’re gonna get.

DoFoo did not get intercepted. So what’s the issue here, and how do we fix it?

The What

When you forward a registration, Windsor runs just the first type through the complete registration pipeline, and subsequent forwarded types are treated just as additional piece of data “Oh, by the way, use this component I just registered for this type as well". Proxy registration is a part of the component model building, and since we end up having just one component only information about its main type gets recorded for proxying.

While this might appear at first clearly as a bug, I think it’s rather a by-design feature. Forcing Windsor to figure it out by itself could pretty quickly become very tricky and we might not always get what we expected. There are however ways of getting what we want.

The fix no 1

Now that we know what we’re up against, how do we fix it? First and the most trivial fix would be simply to make the DoFoo virtual – this way it would get picked when proxying Bar base class and we could successfully proxy it. While this may not always be applicable (you may not be able to modify the class) this is the only option that is available if you’re using the released version. However if you’re using trunk there are two more possible ways of bending it to our will.

Meet my attributes

Due to some changes in how Dynamic Proxy 2.2 (current trunk) handles additional interfaces to proxy, it is possible to intercept non-virtually implemented interface members on a class proxy. Since Windsor by default will request just the class proxy (with no additional interfaces) we need to tell it to toss an IFoo attribute in as well. The quickest way of doing it is throwing an attribute on top of our class:

[ComponentProxyBehavior(AdditionalInterfaces = new[] { typeof(IFoo) })]

public class FooBar : Bar, IFoo

    public void DoFoo()

        Console.WriteLine("DoFoo");

    public override void DoBar()

        Console.WriteLine("DoBar");

If we run the code now we’ll get this:

This is not a solution most people would choose anyway. Even if you can do it (your service does not come from a 3rd party library), you’re decorating your service class with a Windsor-specific attribute which many consider an anti-pattern. There’s however a third, more pure way.

Remember that you need trunk version of Dynamic Proxy for this to work. If you use version 2.1 you’ll end up with this instead:

Windsor will implement the interface, but it will treat it as interface proxy without target. You can make it work by inserting a dedicated interceptor that will forward the calls to your class, but it’s something you’ll have to do manually all the way through.

Black belt approach

I said that forwarded types don’t get ran through whole registration pipeline. However, kernel does raise its component lifecycle events for them, so we can hook up to them and get notified when our forwarding handler gets registered, and modify its component model.

We start by hooking up to kernels HandlerRegistered event, before we register any components.

var container = new WindsorContainer();

container.Kernel.HandlerRegistered += OnHandlerRegistered;

In the OnHandlerRegistered method we check whether the handler at hand is a ForwardingHandler and if so we add its interface to the list of additional interfaces we want to proxy, just like we did using attribute in the example above.

static void OnHandlerRegistered(Castle.MicroKernel.IHandler handler, ref bool stateChanged)

    var forwardingHandler = handler as ForwardingHandler;

    if (forwardingHandler == null)

        return; //we're only interested in forwarding handlers...

    if(!forwardingHandler.Service.IsInterface)

        return; //we're only interested in interface services...

    var targetHandler = forwardingHandler.Target;

    if(!targetHandler.ComponentModel.ExtendedProperties.Contains(ProxyConstants.ProxyOptionsKey))

        return; //apparently this service is not registered for proxying

    var options = targetHandler.ComponentModel.ExtendedProperties[ProxyConstants.ProxyOptionsKey] as ProxyOptions;

    Debug.Assert(options != null);

    options.AddAdditionalInterfaces(forwardingHandler.Service);

Now we get our interface proxied without having to touch our component’ code.

Technorati Tags: Castle Windsor

Mapping different types with NHibernate - IUserType

2009-10-13T01:04:44-07:00

Recently I had a problem with the application I’ve been working on. One of entity types in my domain had a property of type uint. Not a big deal, until you want to store it in Microsoft SQL Server database which does not support unsigned types. I’ve been scratching my head for a moment and then I found a solution – let’s map it as long in our database. Since long can represent any legal value of uint, we should be all good, right? So let’s do it.

public class ClassWithUintProperty

    private Guid Id { get; set; }

    public virtual uint UintProp { get ;set; }

<?xml version="1.0"?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"

                   assembly="NHibernate.Test"

                   namespace="NHibernate.Test">

  <class name="ClassWithUintProperty">

    <id name="Id"/>

    <property name="UIntProp" not-null="true" type="long" />

  </class>

</hibernate-mapping>

"Houston, we've had a problem"

All good. At least until you try to fetch saved value from the database. When you do, you’re up for an unpleasant surprise:

System.InvalidCastException: Specified cast is not valid.

NHibernate.PropertyAccessException: Invalid Cast (check your mapping for property type mismatches); setter of NHibernate.Test.UIntAsLong

The exception is a result of how NHibernate optimizes property access and quirks of mixing different conversion operators (unboxing and numeric conversion in this case) and are not really interesting. What’s important, is that we approached the problem from the wrong angle.

What we’re dealing with here, is inability of our database engine to deal with datatype in our model, which we were trying to solve by pushing this onto NHibernate without telling it something is ‘”wrong”. While NHibernate is smart, it’s working based on a set of explicit information, so what we need to do, is to be explicit about what we want it to do.

There are two places where we can tell NHibernate about it.

IUserType, which will explicitly handle the mapping from uint in our model to long in the DB
custom Dialect which will basically lie to NHibernate telling it “yeah, sure this DB supports uints – whole dozens of ‘em!” and do some work under the covers to live up to its promise. (not shown in this post).

Enter IUserType

IUserType is an extension point in NHibernate that let’s you plug in to the mapping process and handle it yourself. The interface is quite big, but there’s very little real logic there:

public class UIntAsLong:IUserType

        public SqlType[] SqlTypes

            get { return new[] { SqlTypeFactory.Int64 }; }

        public Type ReturnedType

            get { return typeof( uint ); }

        public bool IsMutable

            get { return false; }

        public int GetHashCode( object x )

            if( x == null )

                return 0;

            return x.GetHashCode();

        public object NullSafeGet( IDataReader rs, string[] names, object owner )

            object obj = NHibernateUtil.UInt32.NullSafeGet( rs, names0 );

            if( obj == null )

                return null;

            return (uint)obj;

        public void NullSafeSet( IDbCommand cmd, object value, int index )

            Debug.Assert( cmd != null);

            if( value == null )

                ((IDataParameter)cmd.Parametersindex).Value = DBNull.Value;

            else

                var uintValue = (uint)value;

                ( (IDataParameter) cmd.Parametersindex ).Value = (long) uintValue;

        public object DeepCopy( object value )

            // we can ignore it...

            return value;

        public object Replace( object original, object target, object owner )

            // we can ignore it...

            return original;

        public object Assemble( object cached, object owner )

            // we can ignore it...

            return cached;

        public object Disassemble( object value )

            // we can ignore it...

            return value;

        bool IUserType.Equals( object x, object y )

            return object.Equals( x, y );

There are really two parts of the code that are interesting. SqlTypes / ReturnedType properties which tell NHibernate which types to expect on both sides of the mapping, and the NullSafeGet / NullSafeSet methods which perform the actual conversion.

Now we just need to plug our custom user type to the mapping, and it goes like this:

<?xml version="1.0"?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"

                   assembly="NHibernate.Test"

                   namespace="NHibernate.Test">

  <class name="ClassWithUintProperty">

    <id name="Id"/>

    <property name="UIntProp" not-null="true" type="Foo.Namespace.UIntAsLong, Foo.Assembly" />

  </class>

</hibernate-mapping>

Technorati Tags: NHibernate

Important milestone

2009-10-08T14:53:27-07:00

As of now Dynamic Proxy is passing all the tests under Silverlight. There’s still some work to do, but it is pretty stable the way it is, and it’s been used by Silverlight versions of Rhino Mocks, Moq and probably some others as well for some time.

Technorati Tags: Castle,Silverlight,Dynamic Proxy

Book review - The Seed of Hope

2009-10-07T10:34:00-07:00

The Seed of Hope (Talent Tree)

I used to be a big fan of fantasy and science fiction books back in a day. I read a ton of books by David Eddings, Mercedes Lackey, R. A. Salvatore, Janusz A. Zajdel and countless other authors. I’m still completing my collection of Discworld books, and trying to find some time to read the monstrous (1000+ pages) Lód by Jacek Dukaj. When Pragmatic Bookshelf released their first non-technical book, “The Seed of Hope”, I thought it might be an interesting venture – fantasy book by technical publisher.

We get quite a standard story, variations of which I’ve seen many times, so if you’re expecting some revolutionary plot… there isn’t any. We get the variation of an usual tale of an orphan child going on a trip to unveil its destiny and save the world along the way with the small help of some friends and their magical talents that they learn as they go.

That in itself is not a downside by any means, the whole Belgariad saga (five books, 500+ pages each) are basically following the same idea, with Malloreon (yet 5 more books) reiterating it once again, and I had a blast reading them, although it was close to ten years ago.

I didn’t have a lot of fun reading The Seed of Hope though. First of all, the book is short - less than 300 pages, and it feels like a 700 pages book stripped of content to fit on the limited number of pages. This in turns forced the author to take a lot of shortcuts, not go into a lot of details, and as a result of that – the whole story feels flat. The world is pale, the characters shallow, and the storytelling just scratches the surface of the potential of the world. We don’t get to know the characters well enough to really understand their motivations, and their actions often felt random to me. The big story turning point when good characters crosses to the dark side felt naive for that very reason.

So we end up with a mediocre book. Not a bad one, as it has all the required parts, but the execution leaves a lot to be desired. I think especially younger readers will find it worthwhile. On the bright side, it motivated me to pick up that Carpe Jugulum, that I’ve been meaning to read for quite some time.

How to contribute to open source without writing a single line of code

2009-09-07T04:01:06-07:00

Read the introductory post here first.

So, you found an open source project you really like, it saves you a lot of time, takes some friction away from your life, saves you money and you’re full of admiration and gratitude to the people who spend their free time working on it, so that you can stand on their shoulders. You feel like you really should give back to them, or to the (rest of the) community around the project, but you don’t really want or can do the obvious – start fixing bugs or implementing new features, so you don’t. But is it the only way to contribute to the project? Hardly – you can be of great help to the project without writing a single line of code, and dedicating just a tiny fraction of your time to contributing.

Give feedback

The smallest thing you can do to contribute is give feedback. Developers working on every healthy open source project are constantly looking for users feedback. How would you like a feature to work? How do you like the current feature set? What would be the feature you’d like to see the most in vNext? What behavior in this or that corner case would you find more logical? These the kinds of questions that tend to be asked by the developers to the community, and by speaking your mind on these issues you’re helping the developers make the right decisions.

Some project have set up dedicated websites, using uservoice.com where it’s incredibly simple to give feedback – you just click. For more elaborate questions discussion groups, or project blogs are used to ask open questions to the community. Take a moment of your time to write a few sentences to shed some light on your perspective on the matter. This may not seem like much but giving feedback is the most important thing in ensuring that the project progresses in the right direction.

Help others

For commercial software where there’s a big company behind the product, there are usually people hired to build up the body of knowledge about the product. They write documentation, they write articles in magazines, they blog extensively, speak on conferences write books, answer questions on forums etc. Open source projects have usually just a few volunteers writing code, documentation, blogging, answering questions, all at once and on top of that – they do it in their own free (as in speech) time.

What you can do, is to dedicate some of your own time to take some of the non-coding off of their shoulders. Do subscribe to discussion group of your favorite project, or to your favorite Q&A website where people ask for solutions of their problems with the project. If you see someone asking a question that you know the answer for – do answer. This won’t usually require a lot of time, and someone will be very grateful to you. Also this has another aspect – by stating clearly what you know, or think you know you’re learning better the product itself – you’re building up your expertise and gain recognition and respect in the community. This is especially visible on sites like StackOverflow.com where for giving good answers you’re rewarded with points.

Write documentation

If you find some aspect of using the project hard, and the documentation is not very helpful – improve the documentation. Many projects keep their documentation in the form of a wiki, which means that you’re free to edit and improve it. After all – the documentation is the place where everyone is the most likely to look for solutions in the first place. Help keep it up to date. Help it cover the areas you struggled with. If you blogged your problem – you’ve done most of the hard work already. Add parts of your blog post to the documentation, ensuring that they fit with the rest of the documentation and its rules.

It’s not only the code

Open Source projects are not only the coding and documentation – it’s also all the ‘meta’ stuff. If you can help improving the website of the project. Write the copy. Improve the design of the website. Design logo. This all is important stuff, although often there’s no person to take care of that.

Blog, speak on User Group meetings

If you have a blog – do write about the project. Post solutions event to what after the fact may seem as the most trivial problem. If it took you 15 minutes to figure out, it is worth posting about. You’ll be surprised how many people will find your post helpful.

If you like the project – get others involved. Speak on your local user group meeting about it, show what you like about it, how it helped you, why you like it. By advocating good project you’re getting others involved. You’re expanding the community which means more people learn about it, use it and ultimately more people contribute to the project.

Donate money

Open source projects are free to use, but they certainly are not free to develop and maintain. Contributing with your wallet can be very effective way of helping the project progress, yet many people don’t even consider this. Small amounts to cover hosting costs, costs of hardware bandwidth etc may make make a whole world of difference to the maintainers of the project.

Also developing software often requires software which is not free. You want project X to support version Y of Z? Donating money so that the developers can purchase the license of Z can be a great way of contributing. That is especially true on the Microsoft stack, which consists almost entirely of commercial software.

On the larger scale donating can help someone to start working full time on certain aspects of the project to make what would otherwise be impossible, possible. Probably the most famous example of this is IMeta corporation, which donated one of their top developers to work full time for several months on bringing LINQ support to NHibernate.

How to contribute to open source

2009-08-29T12:01:54-07:00

Once in a while I talk to someone who sais something like this: “I love open source, especially project X – I would love to contribute back, but I don’t know how”. There are different variations. “I am not a programmer”, “I don’t understand the code – it’s so vast”, “I wouldn’t know how to submit these patch-things they ask for” etc.

To help these people I decided to create a small (seriously – 3 posts, excluding this one) series about contributing to open source projects. I hope this will help more people get involved as they realize how much they can help with little effort.

I intend to do the following:

How to contribute to open source without writing a single line of code
How to contribute code to open source project without knowing its inner workings
How to contribute code to open source – reporting bugs and creating patches

This should cover most of the ground to get people started. The topic itself is certainly much broader, and one could write a whole book about it, but why waste time for that, when there’s some great open source waiting for your contribution!

Thoughts on C# 4.0’ optional parameters

2009-08-29T11:58:55-07:00

C# 4.0 is just round the corner and along with it set of nice new additions to the language, including optional parameters. There’s been some historical resistance to add this feature to the language, but here' it is, and I’m glad it’s coming, or at least I was.

In few words, optional parameters, have their default value specified in the signature of the method. You can then skip them when calling method, and the method will be called with their default values.

So, what’s the deal?

To simplify the current discussion I will refer to the method containing default parameters (Foo in this example) as called method, and to method providing the default value (DateTime.Now getter in the example few paragraphs below) as value provider.

Take a look at the code below. Method Foo has two parameters, but we can call them as if it had none.

Looking good so far, right? Let’s take a look at how Main method looks like in Reflector.

As we can see there’s no magic here – simple compiler trick. Compiler binds the invocation to the method, and them puts the arguments for you. The code looks as if you had written it yourself in earlier version of C#.

Still good, right? So how does exactly the compiler knows what to put on the calling side? Let’s take a look at the compiled signature of the method Foo.

Ha! The values are encoded in DefaultParameterValueAttribute. Do you see the problem here? No? Than let’s try something else. Let’s change the signature of the method to take DateTime instead of int.

Notice we initialize the time to default value of DateTime.Now. All good? So let’s compile the code, shall we?

Oops.

Turns out we can’t. What seems like a really reasonable code is not allowed. Since the default values for arguments are being kept in attributes they must be a compile time constants, which includes primitive types (numeric types and strings), tokens ( typeof, methodof, which is not exposed in C# though ) and nulls. Pretty disappointing right? This means no new Foo(), no Foo.Bar is allowed. This dramatically limits the range of scenarios where this feature can be used, as most of the time, you’ll want not null, but something else as your default value, in which case you’ll end up creating overloads anyway.

There are some workarounds, like the one described in this book, but they have their own downsides, and it’s not always possible to use them anyway.

This all makes me think – why did the authors of the language decided to provide such crippled implementation of the feature? I’m not an expert in this matter, but I found a simple way in which the feature could be implemented allowing for far greater range of scenarios.

What if…

Let’s re-examine how this feature works.

The compiler puts the default values of the arguments in a special attribute type on the called method signature.
On the calling side, the compiler reads the values, and puts these of them that were not provided explicitly.

All the work happens at compile time (let’s ignore the dynamic for a moment, we’ll get to that as well) so no additional work at runtime is required. Since the compiler is very powerful, why not go one step further.

I think by simply extending this approach the following scenarios could be enabled.

using value returned by static parameterless method (this includes static property getters) as default value.
using value returned by instance parameterless method defined on the same type (or base type of the type) as called method is defined on (this would only be applicable for instance methods).
using default, parameterless constructors as default value.
or if we wanted to extend it further: using value returning by any variant of the above that does take parameters that are allowed to be put in the attribute (including both constants, and values of other parameters).

Let us examine how this could be (I think) achieved.

The spoon does not exist

What we would need is a way to store information which method, or constructor of which type we want to invoke in case no default value is provided. Since tokens are legal in attributes, the existing approach could be extended with something like this:

We have a way of storing the method. Now, the compiler could easily retrieve the token and invoke the called method.

If value provider is static there’s no problem – just call it, regardless of whether called method is an instance or static method.
If value provider is instance method, and called method is instance method as well, invoke the value provider on the instance on which called method is being invoked (hence the requirement that value provider must be declared on the same type as called method or its base type).
If value provider is instance method but called method is static do not allow (at compile time!) this code to compile, since there’s no instance to call the value provider on.

When it comes to constructors it is even simpler – since we allow only default constructor, at compile time we would check if the type does indeed have default, accessible constructor, and disallow the code to compile otherwise. Then when the called method is being invoked, retrieve the type token and call the default constructor on that type.

What about dynamic code?

I don’t have very intimate knowledge of dynamic code yet, but I think this could work with dynamic code as well. The compiler would put all the information on the call site (new concept introduced in .NET 4.0) and this would be all we need. In C# 1.0 having MethodInfo of a method you could invoke it. Same having System.Type it is easy to find and invoke it’s default constructor using little bit of reflection. I really see no reason why this would not work.

What do you think – am I missing part of the picture – is it something terribly wrong with my idea that would restrain it from working? Or maybe C# team didn’t really want (as they used to) implement this feature so they provided only the minimal implementation they needed for other major features, COM interop specifically.

Technorati Tags: C#

Book review – Debug It!: Find, Repair, and Prevent Bugs in Your Code

2009-08-30T02:00:00-07:00

I bought Release it! some time ago, and it was a really good book. Now Pragmatic Programmer released a new book in their ‘do it!’ series – Debug it!, so when I got a change to snap a copy, I did, and I’m here to let you know that it is a remarkable book.

First of all, I think the title might be a little misleading for some people. It is about debugging in a broader sense than most people define it. If for you debugging equates dealing with debugger, you won’t find much of that in this book. The book talks about debugging as in getting the bugs out of your software (and doing your best to make sure they won’t come back).

The book is divided into three parts:

The first part, which accounts for almost half of the book, talks in great detail about four stages of dealing with bugs in your code – reproduction, diagnostics, actual fix and reflecting over reasons why the bug was there in the first place. There is not much earth shattering here, and when reading this part you’ll (hopefully) think to yourself – “yeah, I knew this” and “sure, it makes perfect sense”. The fact that this all common sense, and rules of thumb are gathered in one place though, and backed up by concrete discussion and good anecdotes helps you organize your workflow when dealing with misbehaving code. The fact that what you felt under your skin is said out loud makes you stop and realize there’s deeper meaning to all this.

Second part is relatively small, but concentrates on very important topic – working with people. That includes both, working with QA department and users as well as working with bug tracking systems. It discusses what makes a good bug report, what it should contain, what it should not contain etc. This part was a revelation, and if I could I would make it mandatory to read for all my clients, and people submitting bugs to OSS projects I contribute to. Then it moves to pragmatic approach towards working with bugs (hey, it’s a Pragmatic Bookshelf book after all). It talks about perfectionist attitude of bug-free software, and working with software that is riddled with bugs, which was interesting to read in the context of Tim’s post.

The final part, is a loosely connected group of topics, though it is as valuable as the previous ones. It talks about special cases, like service releases, about building the ideal debugging environment, which I found particularly interesting as this is topic close to my heart, although I would disagree with the author, who discourages extensive use of branching is source control. We also get a chapter on how to make software easy to debug. The book ends with list of anti-patterns along with discussion about how to remedy them.

I know that this book influenced the way I work now, and there aren’t many books I could say something like this about. It discusses extremely important part of software engineer’s profession, and does it very well. If you call yourself a pragmatic programmer I think you should read this book.

Technorati Tags: Book,Review

Castle blogs – RSS feed

2009-08-29T06:09:46-07:00

One thing I don’t think I articulated clearly enough when announcing Castle Blog Aggregator, was that it comes with RSS feed.

You may have noticed an RSS icon in your browser when browsing the aggregator site, but in case you didn’t here’s the direct link to the feed that you can use in your favorite feed reader.

We’re also open to include other blogs in the feed, so if you blog about Castle, or know any good blogs about Castle project, let us know, either in the comments, or create a suggestion on Castle UserVoice page.

Technorati Tags: Castle