# Operators

Nick Ingolia (ningolia@neon.ci.lexington.ma.us)
Fri, 12 Apr 1996 09:57:45 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    On Thu, 11 Apr 1996, Jefferson M. Dubrule wrote:

    > --- "Robert J. Brown" wrote:
    > C++ has the idea of a "copy constructor" and uses it to instantiate
    > temporary objects on the stack frame of the currently active
    > procedure.  These objects have their destructor invoked when that
    > procedure exits, since that is the end of the lifespan of the
    > temporary object.
    > --- end of quoted material ---
    > Hmm.  I was thinking of using x:_plus(y,temp), passing temp (a copy of x) to
    > the function to use as a return value, and it would be recycled if unneeded.
    > This would be cool, but what if a real object got returned?  Would it be
    > recycled, or would a temporary flag exist?  If a temporary flag existed, what
    > if it got assigned to a property.  Would the temp flag disappear?  What if it
    > were removed from the prop.  It should be recycled, right?  Should a reference
    > count be kept, which recycles the object when references = 0?  It has to
    > interface with some sort of recycler, as having invalid object numbers is
    > considered bad form.  After carefully considering this, I got scared and ran
    > away :)  I'll consider it after all the other stuff I have already planned out
    > is done.
    >
    >

    	It is dangerous to draw direct analogies between objects in C++
    and MOO; the overhead for an object in C++ is just that of any complex
    data type--you only introduce significant speed overhead in your
    constructors and destructors, which you have complete control over.  Your
    storage space is no greater than that required for a struct with the
    variable members of the class.
    	In MOO, there is a *huge* difference between the overhead for a
    variable and the overhead for an object.  The process of creating an
    object requires that you alter inheretence hierarchies, allocate data
    structures to store information about the object, its built-in properties,
    its list of properties (even if it has none), its verbs, etc.  When you
    recycle an object, you must deallocate all these data structures.
    Furthermore, frequent creation and recycling of objects leaves holes in
    arrays in the server that waste memory.  This is why, for example, the
    $recycler system exists--to avoid at all costs the overhead associated
    with the create()ion and subsequent recycle()ing of an object and avoid
    "holes" in the list of object numbers.

    --Nick Ingolia

    ningolia@[oxygen|neon|stu].ci.lexington.ma.us
    ingolia@molbio.mgh.harvard.edu