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
