[self-interest] simplicity

[Steven Shaw]

On Wednesday 30 June 2004 14:25, Toby Ovod-Everett wrote:
> For instance, say I have a class that interacts with the Windows registry. 
> In one block, I access a key and read through its values.  The block closes
> and then I go to delete the key.  If the finalizer for the object that
> interacts with the key doesn't run before I attempt to delete the key, I
> will have problems because the Windows registry system won't allow deletion
> of a key for which there are open handles.  

I agree with the other respondant - I don't think you need to design it this 
way. In this case (i.e your windows registry example), I'm sure you could use 
explicit resource management (hidden away appropriately) and have easy to 
understand, maintainable code. If it gets a little more complicated, it best 
interface may be "transactional".

> The requirement that I always 
> explicitly close objects to ensure that finalizers run immediately begins
> to look an awful lot like the requirement that I hand back malloc'ed memory
> . . . :)

This approaches a good argument against explicit resource management. We know 
that memory management works better when you don't have to manage it 
explicitly. However, in this case you generally have to be happy to have 
finalisation happen "sometime soon". Even with reference counting, you have 
cycles which are collected every now and then by a mark-sweep or something.

I wonder what makes most resources unlike memory? Maybe it's that most 
resources are held for short periods of time (although they say the same 
about memory...). Probably it's more something to do with the number of 
references to a resource. If anyone knows the answer please chime in.