Comments on: Disposing of the IDisposable implementation

By: Code weave helper for the standard Dispose pattern? | FaceColony.org - Developers Network

Sat, 28 Jan 2012 15:22:10 +0000

[...] You can potentially save yourself a little work by having a base Disposable class like in this blog entry. Then you just have a one-liner at the top of each method: [...]

By: The Inquisitive Coder - Davy Brion’s Blog » Blog Archive » The Importance Of Releasing Your Components Through Windsor

Sun, 14 Dec 2008 12:37:56 +0000

[...] Disposing of the IDisposable implementation [...]

By: The Inquisitive Coder - Davy Brion’s Blog » Blog Archive » .NET Memory Management

Sat, 16 Aug 2008 18:44:40 +0000

[...] If you can, try to put this pattern into a reusable base class and make your Disposable Managed Resource holding types inherit from this. An example of this approach can be found here. [...]

By: Quantum Bit Designs » Blog Archive » A Thread-Safe IDisposable Base Class

Wed, 23 Jul 2008 03:48:08 +0000

[...] IDisposable (rarely) we have to look up the recommended pattern. Therefore he came up with an abstract base class that provides the proper plumbing and method signatures. All it takes is deriving from this utility [...]

By: Quantum Bit Designs » Blog Archive » A Thread-Safe IDisposable Base Class

Thu, 10 Jul 2008 11:59:54 +0000

By: kilfour

kilfour — Wed, 02 Jul 2008 17:47:10 +0000

To avoid multiple inheritence one could use a nested class that calls the disposing methods in its parent class and return an instance of the nested class from a context initialising method. Some sort of interface is best defined for the class managing the resources, and an abstract baseclass for the nested class wouldn’t hurt either.
Client code would change from :
using(MyExpensiveResource resource = new MyExpensiveResource()) { resource.DoSomething() }
to :
MyExpensiveResource resource = new MyExpensiveResource() using(resource.AccessResources()) { resource.DoSomething() }
AccessResources needs to initialise the resources and return an instance of the nested class that implements idisposable. MyExpensiveResource would probably change name to MyExpensiveResourceManager at this time, but we are discussing a case where the elegant Disposable solution doesn’t work.

By: Kevin Kerr

Kevin Kerr — Mon, 30 Jun 2008 02:47:30 +0000

This should have had more kicks

By: Ayende Rahien

Ayende Rahien — Sun, 29 Jun 2008 23:13:08 +0000

The full disposable semantics are only required if you are holding an unmanaged resource.
If you are holding only managed resources, you don’t care about that, and can leave the GC to do all the work

By: Davy Brion

Davy Brion — Sun, 22 Jun 2008 08:59:31 +0000

yeah… code readability is very important to me though, so that’s not a direction i’m willing to take

inheriting from Disposable works pretty well for me so far… I always try to avoid large inheritance hierarchies, and i only use class inheritance where it makes sense to me. So i don’t often run into to the issue where i can’t inherit from Disposable. Unless i have to extend a type i don’t have the source to, but in those cases i prefer composition over inheritance (if possible).

By: Yoram

Yoram — Sat, 21 Jun 2008 22:52:48 +0000

Here is how I see it:
- the ICleanDisposable doesn’t inherit from IDisposable
- the Disposable aspect implements the IDisposable interface on the aspected class (through a composite aspect with Postsharp)
- In order to call the Dispose() method implemented by the aspect in your code, you will need to use the following method provided by Postsharp:
K Post.Cast(T myObject)

Using this method will allow your code to compile. At compilation-time, Postsharp will check if myObject (of type T) can really be casted to the K type (IDisposable in our case).

The problem with this approach is that you can’t use the using pattern easily. With the following code:
// Toto is a class implementing ICleanDisposable and which has the Disposable aspect using (var toto = Post.Cast(new Toto())) { // do something }
you won’t be able to call specific methods on the toto instance, as it will be casted to IDisposable… I guess that if we resort to using an old-school try-finally, we could get it to work as expected, but at the cost of making the code less readable.

By: Davy Brion

Davy Brion — Wed, 18 Jun 2008 09:52:21 +0000

Actually, that still won’t be perfect… if your type implements the ICleanDisposable interface, you’re still required to provide a Dispose method to fullfil the IDisposable requirements that ICleanDisposable brings with it.

If the aspect implements the Dispose method, it won’t be known at compile time since postsharp weaves the aspect code in after it’s been compiled. So you wouldn’t be able to compile to code due to the missing required Dispose method

By: Davy Brion

Davy Brion — Wed, 18 Jun 2008 09:38:11 +0000

By: Rob

Rob — Wed, 18 Jun 2008 09:36:35 +0000

and then we get drunk

By: Davy Brion

Davy Brion — Wed, 18 Jun 2008 09:29:16 +0000

ah, so you’d have the type implement the ICleanDisposable interface instead of the IDisposable interface and then from the AOP aspect you’d reference the target class through the interface type and call the DisposeObjects() and ClearReferences() methods at the appropriate time?

That would certainly avoid the multiple inheritance issue

By: Rob

Rob — Wed, 18 Jun 2008 09:24:33 +0000

Maybe something like:

interface ICleanDisposable: IDisposable { void DisposeOjects(); void ClearReferences(); }

By: Davy Brion

Davy Brion — Wed, 18 Jun 2008 09:03:29 +0000

is that a challenge?

seriously though, an AOP solution would be nice, but i don’t know how well that would work… you’d have to make your type implement the IDisposable interface (which is possible with the Composite aspect in Postsharp) but then in your aspect you’d have to be able to recognize which members you’d have to dispose. I’m not sure how you could do that without resorting to reflection, which i’d rather not use in a Dispose method

By: Rob

Rob — Wed, 18 Jun 2008 08:54:20 +0000

I think there still has to be a better way. Maybe some AOP implementation?

By: Davy Brion

Davy Brion — Wed, 18 Jun 2008 06:44:31 +0000

well, you should dispose each object you contain that implements IDisposable… but yeah, there are a lot of classes that implement that interface without necessarily being that expensive so that name is not really correct.

Maybe a simple DisposeObjects() would actually be better?

By: Ifeanyi Echeruo

Ifeanyi Echeruo — Tue, 17 Jun 2008 22:16:25 +0000

Actually the method name DisposeExpensiveObjects is a bit misleading. Dispose is meant for releasing unmanaged resources; OS handles, network connections etc, they dont have to be expensive just outside the reach of the garbage collector.