Now, I guess I'm confused. Are we talking about maintaining a list of
references to a given object? Off-hand, I don't see that a mark and
sweep garbage collection strategy (like the one used in Java) would
require this. What I do see as potentially tricky is that runtime
object would need to be qualified by job number, but that seems to be
a technical detail.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Before one gets the right answer, one must ask the right question."
-- S. Barry Cooper
On Jul 11, 2005, at 4:02 PM, [EMAIL PROTECTED] wrote:
And of course, if Rune was already implemented, the object's
destructor
would already be called by the KILL command anyway, since it would be
part of the contract of the object with the language layer.
The problem with the owner idea is that you need to decide if you
are managing content or address. If a new object is created by the
MERGE
command, then your Garbage collection is managing addresses (ie:
names of
global references etc.) If a MERGE results in just another location
where
the content is stored, then you need to keep track of the content
changes.
Anyway, the owner idea is useful enough to remember when I dabble
in dynamic
object manipulation again.
Fascinating stuff, but mostly at right angles to typical VistA
development.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
