At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote:
There may be cases where the object being managed is not a resource per-se, but that doesn't mean that the mechanism is misnamed as a 'resource manager'; it's just the most common use case that any of
have managed to think of (as of yet).
This is possible. I just wanted to expand everyone's minds :)
Stick by your guns. The mechanism is more general than resource management. Like decorators, the encapsulation of a try/finally wrapper is completely generic and not married to the resource management context.
Expand your mind. :) "Resource" can include whatever objects you want it to -- or no objects at all. A resource can be conceptual - like for example the user's attention, or the contents of a status bar or log message, or the timing/profiling of an activity. I think maybe you're projecting one particular concept of "resource management" (acquisition/release) and therefore say it's too narrow. But that's like I'm saying "vehicle", and you think that means "car".
Should we give mind-expanding examples of "resource"? Yes, sure. But it's easier to say and teach "resource management" first, and then expand the concept, than to start with some more nebulous concept and then say, "but mostly you're going to use it to manage resources of various kinds." :)
If you did want to start with something vague, you could always call it "context management", and call the objects "context listeners", saying that the "with" statement defines a context in which its body occurs, and the context listener is notified of the context's entry and exit. But I don't think that this really works as the primary explanation; I think it's better as a mind-expanding "Another way to think of this is..." add-on to the simple resource management explanation.