Comments on: Compiler Enforced Disposal? http://davybrion.com/blog/2008/11/compiler-enforced-disposal/ Trying to walk that thin line between intelligence and ignorance Thu, 11 Mar 2010 23:14:12 +0100 http://wordpress.org/?v=2.9.2 hourly 1 By: Davy Brion http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5162 Davy Brion Tue, 18 Nov 2008 12:09:44 +0000 http://davybrion.com/blog/?p=585#comment-5162 nope, there is no real drawback to calling Dispose() methods that aren't really required. The only 'drawback' is that it's just more code than is needed. nope, there is no real drawback to calling Dispose() methods that aren’t really required. The only ‘drawback’ is that it’s just more code than is needed.

]]> By: Jeremy Wiebe http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5161 Jeremy Wiebe Tue, 18 Nov 2008 12:05:23 +0000 http://davybrion.com/blog/?p=585#comment-5161 I agree with Den Ben also... I'd add that having the compiler enforce disposal would be difficult to get right. For instance, I usually say that the class that creates should be the class that Dispose()es. There's a whole bunch of situations where a class may have a reference to an IDisposable, but should not be the one Dispose()ing it. This would be especially true for objects created through an IoC container. Also, is there any severe drawback to calling Dispose() on classes that don't require it (other than having a few extra using() blocks around)? I agree with Den Ben also… I’d add that having the compiler enforce disposal would be difficult to get right. For instance, I usually say that the class that creates should be the class that Dispose()es. There’s a whole bunch of situations where a class may have a reference to an IDisposable, but should not be the one Dispose()ing it. This would be especially true for objects created through an IoC container.

Also, is there any severe drawback to calling Dispose() on classes that don’t require it (other than having a few extra using() blocks around)?

]]> By: Neal Blomfield http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5127 Neal Blomfield Mon, 17 Nov 2008 19:27:39 +0000 http://davybrion.com/blog/?p=585#comment-5127 I have to agree with Den Ben. An interface is a contract that explicitly defines the interaction between client and server. If something is implementing IDisposable and it doesn't need disposing 2 things should happen: 1. Remove IDisposable from the list of interfaces the class implements and marked the Dispose method with [Obsolete] 2. Find the developer(s) that made the choice to mark classes not requiring disposal with IDisposable and whack them across the knuckles with a steel rule (my old woodwork teachers favourite method of making a lesson out of a poorly chosen action) =) I have to agree with Den Ben. An interface is a contract that explicitly defines the interaction between client and server. If something is implementing IDisposable and it doesn’t need disposing 2 things should happen:
1. Remove IDisposable from the list of interfaces the class implements and marked the Dispose method with [Obsolete]
2. Find the developer(s) that made the choice to mark classes not requiring disposal with IDisposable and whack them across the knuckles with a steel rule (my old woodwork teachers favourite method of making a lesson out of a poorly chosen action)

=)

]]> By: Jan Van Ryswyck http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5117 Jan Van Ryswyck Mon, 17 Nov 2008 15:17:48 +0000 http://davybrion.com/blog/?p=585#comment-5117 If C# finally gets those compiler hooks (as Anders promised) the same way like the Boo compiler supports them, then you can role out your own mechanism. Alas I think this is a C# 5.0 feature :-( If C# finally gets those compiler hooks (as Anders promised) the same way like the Boo compiler supports them, then you can role out your own mechanism. Alas I think this is a C# 5.0 feature :-(

]]> By: Jan Van Ryswyck http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5111 Jan Van Ryswyck Mon, 17 Nov 2008 14:30:33 +0000 http://davybrion.com/blog/?p=585#comment-5111 I like the idea. I like the idea.

]]> By: Dew Drop - November 17, 2008 | Alvin Ashcraft's Morning Dew http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5108 Dew Drop - November 17, 2008 | Alvin Ashcraft's Morning Dew Mon, 17 Nov 2008 12:57:24 +0000 http://davybrion.com/blog/?p=585#comment-5108 [...] Compiler Enforced Disposal? (Davy Brion) [...] [...] Compiler Enforced Disposal? (Davy Brion) [...]

]]> By: Davy Brion http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5106 Davy Brion Mon, 17 Nov 2008 11:28:48 +0000 http://davybrion.com/blog/?p=585#comment-5106 good point about it not always been clear wether or not we're dealing with an instance that has the attribute or not and yeah, if Microsoft had been very clear about the IDisposable interface/contract from the start, and if everyone had followed the conventions than all of this wouldn't have been such a big deal... but the way it is now with all the confusion and the conflicting advice is just terrible. Especially when some BCL developers even think you should just rely on finalization... that is just wrong on so many levels IMHO good point about it not always been clear wether or not we’re dealing with an instance that has the attribute or not

and yeah, if Microsoft had been very clear about the IDisposable interface/contract from the start, and if everyone had followed the conventions than all of this wouldn’t have been such a big deal… but the way it is now with all the confusion and the conflicting advice is just terrible. Especially when some BCL developers even think you should just rely on finalization… that is just wrong on so many levels IMHO

]]> By: Cornelius Gouws http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5105 Cornelius Gouws Mon, 17 Nov 2008 11:20:36 +0000 http://davybrion.com/blog/?p=585#comment-5105 The problem with adding an attribute to force the compiler to throw compile time exceptions is that the compiler cannot always know if the attribute is there. If you have a method: <code> private IDisposable GetObject(bool b) { // Return an IDisposable that is marked with // the RequiresDisposal attribute if b is true // else an IDisposable that is not marked with // the RequiresDisposal attribute. } </code> Then if the GetObject method is invoked the compiler would not be able to see if the RequiresDisposal attribute is present and will at best throw a Runtime exception. But as you mentioned if the use of the IDisposable has been standardized from the start (and those standards actually followed) we would not be sitting with this issue now. The problem with adding an attribute to force the compiler to throw compile time exceptions is that the compiler cannot always know if the attribute is there.
If you have a method:

private IDisposable GetObject(bool b)
{
// Return an IDisposable that is marked with
// the RequiresDisposal attribute if b is true
// else an IDisposable that is not marked with
// the RequiresDisposal attribute.
}

Then if the GetObject method is invoked the compiler would not be able to see if the RequiresDisposal attribute is present and will at best throw a Runtime exception.

But as you mentioned if the use of the IDisposable has been standardized from the start (and those standards actually followed) we would not be sitting with this issue now.

]]> By: Davy Brion http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5076 Davy Brion Sun, 16 Nov 2008 21:58:10 +0000 http://davybrion.com/blog/?p=585#comment-5076 well, i thought of the attribute to distinguish between IDisposables where it's not that important that you dispose of them, and IDisposables where you really, really should. I know that a lot of IDisposables still call Dispose in their Finalizer method if the object hasn't been Disposed of so you could argue that there are _no_ IDisposables that really require being Disposed of. But Finalizers can lead to other performance issues, so i don't think that all IDisposables actually use that approach. well, i thought of the attribute to distinguish between IDisposables where it’s not that important that you dispose of them, and IDisposables where you really, really should.

I know that a lot of IDisposables still call Dispose in their Finalizer method if the object hasn’t been Disposed of so you could argue that there are _no_ IDisposables that really require being Disposed of. But Finalizers can lead to other performance issues, so i don’t think that all IDisposables actually use that approach.

]]> By: den Ben http://davybrion.com/blog/2008/11/compiler-enforced-disposal/comment-page-1/#comment-5074 den Ben Sun, 16 Nov 2008 21:23:20 +0000 http://davybrion.com/blog/?p=585#comment-5074 I like the idea of a compiler enforcing the disposing of IDisposable objects. However, I think the fact that an object implements IDisposable should be enough as is. I do not see any reasons to introduce a RequiresDisposal attribute for that. I like the idea of a compiler enforcing the disposing of IDisposable objects. However, I think the fact that an object implements IDisposable should be enough as is. I do not see any reasons to introduce a RequiresDisposal attribute for that.

]]>