By a dynamic object, we mean anything which is created using the CREATE syntax. 

Rule 1) You create it, you delete it. (aka Mary's mantra)

Corollary 1) If you didn't create it, you don't delete it. (Oops corollary)

Corollary 2) Any procedure which will not have enough information to know when to delete 
a dynamic object shouldn't be creating it. (Design corollary)


Rule 2) There are only two valid patterns for creating a dynamic object, inline and 
factory:

  Pattern 1: Inline -  all inline creations look like this:

        create object-type x.
     do on endkey undo, leave on error undo, leave on quit undo, leave on stop undo, 
leave:
       /* Work with object */
     end /* do on ... */.
     delete object x.
     assign
       x = ? /* Not sure this is still necessary - can't hurt */
       .
     
  Pattern 2: Factory model: There is a persistent / super procedure which is responsible 
for the particular implementation of object x, usually it is responsible for all x 
objects. Hence it will have procedures / functions like 
    assign
      x = createAnObjectOfTypex ( creation, parameters )
      .         
  
    run deleteThisObjectOfThisType ( x ).

or
 
    publish "ImDoneWithThisObject" ( x ).


Rule 3)  Any object-type which has a factory should always be created in the factory. 
Inline creation is only for objects which are not managed via a factory. 


Rule 4: AppServer super / persistent procedures should always respond to an 
initialization event which every appServer interface procedure should publish. When the 
event is fired, the factory destroys all objects created in any prior session. (Surgery 
rule - clean up first, then operate.)


Rule 5: Framework authors never turn over control to code developed outside the framework 
with out first creating a widget-pool.

     e.g.,

        create widget-pool.
     do on endkey undo, leave on error undo, leave on quit undo, leave on stop undo, 
leave :
       run value ( codeDevelopedOutsideFramework ).
     end.
     delete widget-pool.



Understanding and following these rules should pretty much keep you out of trouble. I've 
left the details of the factory implementation out of the rule set; I think that is best 
covered via discussions on factory models.


--
Greg Higgins
CodeCrafters (a PEG Holdings company)
The cutting EDGE of PROGRESS