Yeah, why didn't you guys get busy and get that Rune
up and going already? :-)
When you talk about content vs. addresses, this is the
same concept in c/c++ as pointers vs. the actual
memory that was allocated. Sure, anytime that memory
is freed, all pointers to it (and in M this would be
the name of the reference etc.) suddenly become
invalid. Thus programmers have to be very careful
with their pointers, or the entire program goes south
in a big way.
So if I was going to implement this, I would have all
"objects" created through an instantiator, and
destroyed with a destructor.
Tell me what you think. (Code below). I don't think I
have all the indirection syntax correct, but I maybe
you can get my idea. I haven't developed how I would
implement object inheritence, but it wouldn't be too
much of an extension.
Kevin
;------------------------------------------
; new and delete functions below
;------------------------------------------
new(Type)
new typeRef set typeRef=""
new defProc set defProc=$get(TblConstructor(Type))
if defProc'="" set [EMAIL PROTECTED]
quit typeRef
delete(pRef)
new Type set [EMAIL PROTECTED]@("TYPE")
new killProc set killProc=$get(TblDestructor(Type))
if killProc'="" do
. new ID set ID=$piece(pRef,"(",2)
. set ID=$piece(ID,")",1)
. set killProc="do "_killProc_"("_ID_")"
. xecute @killProc
quit
;------------------------------------------
; Setup for available objects below
;------------------------------------------
Init()
set TblConstructor("WIDGET")="defWidget"
set TblConstructor("GADGET")="defGadget"
set TblConstructor("SPROCKET")="defSproket"
set TblConstructor("LEVER")="defLever"
set TblDestructor("WIDGET")="killWidget"
set TblDestructor("GADGET")="killGadget"
set TblDestructor("SPROCKET")="killSproket"
set TblDestructor("LEVER")="killLever"
quit
;------------------------------------------
;Object Widget specif code below
;------------------------------------------
defWidget(New) ;"A constructor for object Widget
set oWIDGET("LAST ID")=$get(oWIDGET("LAST ID"))+1
new ID set ID=oWIDGET("LAST ID")
set oWIDGET("INSTANCES",ID)=""
;"Here we define the default values for object vars
set oWIDGET(ID,"TYPE")="WIDGET"
set oWIDGET(ID,"MyVar1")=0
set oWIDGET(ID,"MyVar2")=0
set oWIDGET(ID,"MyVar3")=0
set oWIDGET(ID,"Multiply")="wgtMultiply"
set oWIDGET(ID,"Divide")="wgtDivide"
quit $name(oWIDGET(ID))
killWidget(ID) ;"A destructor for object Widget
;"any needed clean up code would go here first.
kill oWIDGET(ID)
kill oWIDGET("INSTANCES",ID)
quit
wgtMultiply(x,y) ;"Widget member function
new result set result=x*y
quit result
wgtDivide(x,y) ;"Widget member function
new result set result=x/y
quit result
;------------------------------------------
;Main function below
;------------------------------------------
MyFunct()
new pWidget ;"will store a name of object
set pWidget=$$new("WIDGET")
new done set done=0
for do quit:(done)
. new x,y
. read "input x: ",x,!
. if x="" set done=1 quit
. read "input y: ",y,!
. if y="" set done=1 quit
. new fn set [EMAIL PROTECTED]@("Multiply")
. write [EMAIL PROTECTED]@(x,y),! ;<-- not sure if works(?)
do $$delete(pWidget)
write "That all folks!",!
quit
--- [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.
>
> 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
>
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.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
