Hi, I'm not entirely familiar with the internals of Cocoon, so please bear with me. However, my main point is two-fold:
-there is a difference in practice between recycling reusable components and "real" garbage collection -are we sure that removing the responsibility for management of reusable components from the developer will reduce complexity or support best practices? > With an explicit release() you are in the same boat as the GC > method. For Cocoon we have a really simple lifelength for > requested components: the length of a request. It's not that > hard to implement or to comprehend. It is also pretty easy > to manage the instances available. Admittedly, for Cocoon it may be very easy to tell when a call to the recycler/GC is to be executed...but for other containers, is this necessarily so? If not, it may lead to difficult management of GC/recycle policy. Are we sure that we want to play "Indian-giver" with the developer, who may think that since he has not explicitly released the resource, he may still use it? What if the developer's process is some sort of open-ended session or transaction? > Are timeouts sufficient? No. Does it add additional > complexity for the container? Yes. Does it help the developer? > absolutely. IMHO, auto-magically returning things to the pool seems like a nice feature of the container at first blush, but what it really does is reinforce sloppy programming by the developer, or at least make him adjust his mindset each time he switches between containers and their differing policies. That's added complexity for the developer, not less. The onus for returning borrowed resources should be on the developer, because he best knows when he is finished using them. I suppose I'm just stubbornly resistant to the idea of losing responsibility for the objects running around in my code. No, I guess I mean I don't want to lose *control* over those objects. ;) From the developer's point of view, it would be nice to know that objects I'm using won't disappear according to some ad hoc recycling policy, but it's also comforting to know the container will clean up after me if I'm sloppy. Oh, the rock and the hard place... Regards, Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
