Phil, > It occurred to me that one of the main problems with IDisposable is the > lack of guarantee that finalization will take place as there is virtually > no way to even warn the programmer that they are misusing a class derived > from IDisposable - e.g. the programmer is not ensuring that a resource is > disposed within a try/finally block, a using clause or that in the case of > a class which stores a reference as a member variable that the class itself > implements IDisposable. > > Now, it occurred to me that one way of ensuring that a disposable resource > is disposed of correctly would be to enforce an ownership rule, whereby a > disposable resource MUST always have an assigned owner.
I'd add an additional constraint you don't seem to impose, which covers (at least for me) another very important aspect of this: Not only should the resource have an assigned owner: It should have _only_ one assigned owner. That's the easiest way (at least in theory) of ensuring IDisposable::Dispose() is called only once. Now, I say easiest in theory, because it is not so clear in practice. For many cases, you could say that the first 'scope' (and I use the term in a liberal form here) that acquires the resource should be the owner of it. However, this rule breaks if the virtual ownership is transfered. I'm not exactly sure how such transfer could implemented in a clean, sort-of-generic way, though... > This assigned owner could be a class instance, but could also be a scope > block, local function scope, or assembly scope. Indeed, I think that, for most common escenarios, block or function scope would be the most useful solution. Unfortunately, your solution proposed below, based on interfaces, doesn't seem to really apply completely here, although it could, at least somehow, be sort of worked around in C# by having the compiler inject some extra special code for the "using" statement (which is, in essence, a claim of ownership on the resource)... -- Tomas Restrepo [EMAIL PROTECTED] You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
