It's *really* difficult to participate in this sort of exchange with a Lotus Notes mailer. Bear with me.
Gordon says: "If views held a reference to the storage, then storage = None wouldn't kill the storage. You'd have to have a storage.close() which should either close all views (so you'd have storage -> view references, ie, circular), or perhaps throw an exception if any view is still open, or just silently wait for GC (which would mean we'd have to make storage objects GC containers). You'd still have surprises." Certainly a mechanism could be designed whereby storage.close() would close all views even while the storage has references to the views and the views have references to the storage. Or alternatively, throwing an exception together with a method for returning the list of all open views would be a workable approach. I don't think that in either case you would have what would be surprises since this behavior would be absolutely uniform, predictable, and documented. As it is, the documentation really needs to contain a caveat along the lines of "Warning: Storages and views don't behave as you would normally expect Python objects to.". Now the consequences of this *are* a surpise -- as evidence for which note the current discussion and the fact that at least some of its participants were surprised. A response may be along the lines that these things really do behave as Python objects do -- so long as you understand a great many of the details of reference counting, GC, etc. But this is in the tradition of arguments that Lotus developers and trainers give in arguing that Notes really does work in a coherent and reasonable manner -- once you grasp its design philosophy and inner beauty :-). To me, the bottom line is that (ideology aside) I seem to need to treat Metakit storages and views differently than I treat other "normal" Python objects. And I need to take special care in handling these in ways that I don't need to take special care in handling other Python objects. As I say, I can live with this. But I would prefer a situation that is uniform, predictable and can be documented so that the average programmer who just wants to use Metakit (rather than understand its implementation details) can use it with confidence and without surprises. Compare this to, for example, BSDDB. In many ways Metakit is much easier to use that BSDDB, but BSDDB does not seem to have such surprises. If at all possible, I would prefer a solution in Metakit that yielded similar results. -------------------------------------- Gary H. Merrill Director and Principal Scientist, New Applications Data Exploration Sciences GlaxoSmithKline Inc. (919) 483-8456 _______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
