I just noticed that apparently this was just sent to Gordon rather than the
list.
--------------------------------------
Gary H. Merrill
Director and Principal Scientist, New Applications
Data Exploration Sciences
GlaxoSmithKline Inc.
(919) 483-8456
----- Forwarded by Gary H Merrill/PharmRD/GSK on 21-Nov-2003 13:47 -----
Gary H Merrill
DES Centennial Campus Laboratory
Venture Building II, 920 Main Campus
Drive , Suite 120
21-Nov-2003 12:42 Raleigh, NC 27606
To: [EMAIL PROTECTED]
cc:
Subject: Re: [Metakit] Storage
persistence in Python (was: Passing views in
Python)
I don't think I understand what Gordon is suggesting -- and this is partly
because there are still some things I don't understand about Python
scoping, reference counting, etc. and partly because there are some things
I don't understand about how Metakit does things.
However, opening up potentially a fairly large number of storages which you
stuff into what are basically global variables just so they don't disappear
on you, and leaving those things open (and presumably using memory to at
least some degree) doesn't seem to be an especially good practice. You
wouldn't normally open a file when you need it and then just leave it open
until you terminate the entire application (if, for example, the
application manipulates a large number of files). You wouldn't normally do
that with a database either. The 'open/use/close' model generally has
benefits that the 'open and just leave open' model does not. And this
feels like the same kind of thing to me. But perhaps I misunderstand.
The particular situation confronting me is where I open an existing storage
and get its view. That view (and the storage) are then never changed
(think of it as read-only), but a number of other views are then created
based on that one and passed to a variety of classes for further processing
and display. Some of these views may then be "saved" at some point, but
not in that original storage. But many will be transient and only for
intermediate purposes. So I'm not really interested in doing a commit() on
any of these.
Intuitively, it seems as though a storage ought to remain in existence so
long as you have a reference to a view that is in any way based on that
storage. And the storage ought to go away when you no longer have any
references to it (however indirectly). This just seems to be a description
of the memory management (object management, reference management) model on
which the language is based. If for some reason (having to do with the
underlying implementation of some of the objects involved) this is not
possible, then these objects just seem to violate that fundamental model.
It seems as though in the current situation views and storages fall into
this class. I can live with that. But ideally it seems as though it
shouldn't be the case.
On the other hand, it may be that I'm just not thinking along the right
lines here.
--------------------------------------
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
