RE>Re- strong pointer regi

[heh <heh@xxxxxxxxxx>]

Reply to:   RE>Re:  strong pointer registr
The point is, registration has nothing at all to do with FM.  It is purely a
side effect  (or requirement) of our particular use of our particular garbage
collector.  I therefore don't feel that we should muck up the FM interfaces
with environment dependencies.  Put that in some other place.  It's fine for
there to be a single implementation for all front-ends that need garbage
collector defense.  In fact, that job will certainly be needed for more than
just FMBuildings.  Ergo, don't have one implementation for FMBuildings, another
for Scaffolds, another for FMEvents, another for...

--Hugh

--------------------------------------
Date: 7/28/90
To: heh 
From: roger@xxxxxxxxxxx
Received: by xanadu.com; 28 Jul 90 16:08:58
Received: by xanadu  (4.1/SMI-4.0.2) id AA18150; Sat, 28 Jul 90 16:05:49 PDT
Date: Sat, 28 Jul 90 16:05:49 PDT
From: roger@xxxxxxxxxxx (Roger Gregory)
Message-Id: <9007282305.AA18150@xanadu >
To: heh@xxxxxxxxxx, ravi@xxxxxxxxxx, roger@xxxxxxxxxx
Subject: Re:  strong pointer registration
Cc: xtech@xxxxxxxxxx

I checked the code in question, it holds onto the builders in
an system independent way.  Why does your code hold them in
a system dependent place?

Thje interface presented is that the builder module has a building regestration
book
that keeps track of what buildings exist,  the application modifies that
through
regester & unregester commands.

I expect this "where it is used" is a bad place to put such things,
they can and will be "used" all over the place, this way gives us a central
location to check what is regestered, rather than having to devine what code
might want to do this itself.