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.
David
>
> In Borland's VCL, every object that is created must
> supply an Owner parameter. Then, during creation,
> that owner is notified of the new object, and they add
> it to their list of objects they are responsible for.
> Then, whenever an object is deleted, its destructor
> makes sure to destroy all the objects that it is
> responsible for. This helps prevent lost memory
> allocations, though Borland also uses other methods as
> well to ensure appropriate garbage collection.
>
> I would think a similar system could be used for M
> "objects". But the programmer would have to be sure
> to call the "object's" destructor rather than just
> killing it.
>
> Kevin
>
>
> --- Gregory Woodhouse
> <[EMAIL PROTECTED]> wrote:
>
> > I'm not entirely sure I understand your point here,
> > but if you do
> > intend to use array names as object references
> > (which is what I
> > generally do), and if you need a numeric object ID,
> > then it seems
> > reasonable to require that every object implement a
> > getID() method.
> > I'm not sure if non-persistent objects (any
> > objects?) really need
> > numeric IDs so long as the array references are
> > well-defined and unique.
> >
> > ===
> > Gregory Woodhouse
> > [EMAIL PROTECTED]
> >
> > "Perfection is achieved, not when there is nothing
> > more to add, but
> > when there is nothing left to take away."
> > -- Antoine de Saint-Exupery
> >
> > On Jul 11, 2005, at 3:26 PM, [EMAIL PROTECTED]
> > wrote:
> >
> > > The only problem I had with that kind of approach,
> > when I played with
> > > it years ago, was that there isn't an easy way to
> > know what temporary
> > > object get created by subroutine calls.
> > >
> > > ie: you can do this
> > > MERGE
> >
> @("RESULT="_$$ObjectCreating^Call(possible,arguments))
> > >
> > > with ObjectCreating^Call being code that creates a
> > new object on
> > > the fly as the result of the call. (perhaps using
> > ^TMP($J, or
> > > something
> > > like that as a temporary storage location.)
> > > The problem is recognizing which ones are still in
> > use and which
> > > ones need to be garbage collected.
> > >
> > > MUMPS indirection (ie: extremely late-binding) is
> > very useful, but
> > > using it in a disciplined way is tricky at times.
> > >
> >
> >
> >
> >
> -------------------------------------------------------
> > 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
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> 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
>
-------------------------------------------------------
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
