C# doesn’t have support for arbitrary wrapping out of the box, but you can use Castle’s DynamicProxy (http://www.castleproject.org/dynamicproxy/index.html) to slice in similar aspect-oriented programming behaviors. One way we use this at work is to check thread execution permissions for given routines by sticking [AllowedThread("UI")] attributes on functions.

for example if you want to bracket a function in a begin/end pair you can write a begin/end decorator for a function:

def beginEndBracket(func):
    def wrapper(*arg):
        beginX()
        res = func(*arg)
        endX()
        return res
    return wrapper

@being_end_bracket
def somefunctionThatNeedsToBeBracketed():
     drawSomeSnappyDirectXStuff

When you call somefunctionThatNeedsToBeBracketed() it does

Notice the closure.

I mostly use this for timing functions and class methods.

http://scottbilas.com/blog/finalizers-an-incomplete-pattern/

As a side note, I really dislike finalizers. I heard that Microsoft has seen the light and is quietly phasing out their usage of them as well.

I just looked at an IDisposable class in Reflector, and there’s nothing finalizer-related in there. Unless you mean that the CLR is doing something deep inside, which sounds unlikely to me.

Regarding which gc it ends up in – it again goes back to the relative costs of the disposer from whatever operations it is bracketing.

I’m not entirely sure if it’ll prevent the object from being promoted to the next GC generation though, it still might.