features matrixintro pageEditor's Note: The discussion here should be extended to handle casesin distributed systems in which referenced objects become unreachable dueto, e.g., communication or site failures. Some of these issues could alsobe characterized in terms of what sort of responses to requests or messagesare legal (e.g., is "message could not be delivered" a legitimateresponse, as distinct from, say, "message not understood"?).
OODBTG Reference Model
The "life" of an object is the period during which it exists.An object's life begins as the result of a "create" operation.An object's life ends as the result of a "destroy" operation.An object whose life begins and ends within a single process is calleda "transient". An object which lives longer than the executionof the process that created it is called a "persistent". Someprimitive objects such as literals, have eternal lives, are neither creatednor destroyed, and represent themselves.
An object is "reachable" if and only if there is an operationthat returns the object as a result. The "transitive closure"of an object is all objects contained directly or indirectly within theobject, or more generally all objects reachable from the object directlyor indirectly by repeated application of some filtering predicate. Theterm "navigation" is often used when moving from object to object,possibly through a sequence of move operations.
An object is perceived to exist if and only if it is reachable. If nooperation exists that will return the object as a result, then the objectis "unreachable" (though it may or may not be physically destroyedand system-internal operations may or may not still keep track of the object.)Destruction of an object makes it unreachable. Operations which renderan object unreachable have the effect of destroying the object.
Rules for creating and destroying objects are system dependent. In someobject models systems, the application explicitly invokes creation anddestruction operations; in others, some sort of implicit scheme based on"referential integrity" insures that objects that other objectsdepend on cannot be explicitly destroyed as long as the other objects continueto exist. See entries under 9.4 containment and 2.4 specificationof behavioral semantics.
At the implementation level, destruction or deletion of objects mayinvolve reclaiming the storage space occupied by such objects. Some systemsallow a destroyed object's object identifier to be reclaimed for laterreuse; others do not. Schemes like "garbage collection" or "referencecount" may be used to manage and reclaim space associated with destroyedobjects.
OMG CORBA IDL
Objects can be created and destroyed. From a client's point of view,there is no special CORBA mechanism for creating or destroying an object.Objects are created and destroyed as an outcome of issuing requests. Theoutcome of object creation is revealed to the client in the form of anobject reference that denotes the new object [CORBA Specification 2.2.2Requests].
ODMG
Object lifetime is orthogonal to type, is specified at object creationand, once specified, cannot be changed (there is some discrepancy betweensection 2.3.2.7 which discusses lifetime and section 2.3.2.6 where thecreate operation is discussed and makes no mention of lifetime). Lifetimecan be "coterminous with procedure" meaning it is declared inthe heading of a procedure, allocated out of the stack and returned tothe free pool when the procedure ends, "coterminous with process"meaning it is allocated by the programming language runtime, or "coterminouswith database" meaning it is managed by the DBMS runtime.
Lifetime is not applicable to literals (immutable objects). Literalsalways exist implicitly. Most queries return literals.
The query language contains expressions for constructing objects, butthere is no mention of lifetime of these objects.
EXPRESS
Not an issue as it is a conceptual schema language.
Open Distributed Processing
Lifecycle issues are treated differently in ODP depending on whetherthe issue is being dealt with from an engineering (functional architecturalpackaging) or an implementation perspective.
ODP distinguishes between creation and introduction ofan object. Creation of an object is the action of instantiation,resulting in the existence of a new object. Instantiation of an objecttemplate is an object produced from a given object template and other necessaryinformation. The object exhibits the features specified in the object template.A template is the specification of the common features of a collectionof objects in sufficient detail that an object can be instantiated usingit. (An object template is an abstraction of a collection of objects).Instantiation of an object template may involve actualization of parameters,which may in turn involve instantiating other (object) templates or bindingof existing interfaces. Introduction of an object is instantiationof an object, when it is achieved by a mechanism which is not covered bythe model. (Any object is either created or introduced, but not both.)
Deletion of an object is the action of destroying an instantiated object.
Editor's Note: I believe that from a computational perspective, referencesmay exist to objects or interfaces that "disappear", either becausethey are deleted, or because of failures.
Management Information Model
Instances of an object class may be created or deleted either explicitlyor automatically. Yet, once created these instances have identical behaviors.Explicit creation or deletion means that instances are created using theCMIS M-CREATE service or deleted by using the CMIS M-DELETE service atthe request of a managing system.
The create operation creates a managed object of the specified managedobject class, or a managed object of a compatible managed object class(if allomorphism is supported). The containing (superior) managed objectmust already exist before a contained managed object can be created. Ifthe superior managed object is not specified in the create request (eitherdirectly through the Superior object instance parameter or indirectly throughthe instance name specified in the Managed object instance parameter),the managed system assigns a superior object instance as well as the instance'sRDN. If the Superior object instance is specified in the create request,the managed object is created within that superior managed object.
Automatic creation or deletion refers to an object instance being eithercreated or deleted automatically by the managed system (e.g., NE) basedon some predefined occurrence. These object instances are created withthe conditional packages that the managed system supports and with allof the mandatory packages. Depending on the managed object class definition,the objectCreationNotification and the objectDeletionNotification may beemitted upon automatic creation and deletion to notify the managing system.
Creation and deletion rules of a subordinate object may be specifiedvia the name binding template. Multiple name bindings may be defined foran object class with the same superior object class but with differentcreation and deletion behavior.
SQL3
An ADT instance can exist in any location that an ADT name can be referenced.However, the only way that any ADT instance can be stored persistentlyin the database is to be stored as the column value of a table. For example,in order to store instances of an employee_tADT (see 7. Types and Classes) persistently in a database, a tablewould have to be created with a column having the ADT as its data type,such as the emp_data columnin:
CREATE TABLE employees ( emp_data employee_t );
There is no facility in SQL3 to name individual instances of an ADT,and to store them persistently in the database using only that name. Similarly,there is no central place that all instances of a given ADT will exist(a built-in type extent), unless the user explicitly creates such a place,i.e., by defining a table in which all instances are stored. Thus, in SQL3it is not necessarily possible to apply SQL query operations to all instancesof a given ADT. The instances must first be stored in one or more tables(as column values).
A row in a table exists until it is deleted. Deletion of an ADT instanceis done by deleting the row in which it is stored.
See also 7. Types and Classes.
Matisse
The designers of Matisse felt that garbage collection was inappropriatefor commercial production databases. Version collection occurs at the discretionof the user. If all version collection is done immediately, the databaseoperates like current database systems which have no inherent knowledgeof object history.
Typically, version collection is done on a user-specified, periodicbasis after execution of a "save time" function which flags ahistorical logical time as a view of the database that should not be collected.Reporting or on-line backup can be done without locking by executing readson the "save time" view of the database. If reporting or backupis done at low priority, this has negligible effect on performance of productiontransaction processing. When historical versions are no longer needed,they may be version collected at the discretion of the user.
Matisse is designed to retain knowledge of all historical states ofthe database through systematic archival of version collected objects.
C++
The life-cycle for an object begins when it is created, and ends whenit is destroyed. In a C++ class definition, a member function with thesame name as the class is a constructor. This is a function whichis called automatically whenever an instance of the class is created. Constructorsare typically used to initialize the data members of the object to theirdefault state, but may also be used to allocate resources (memory, files,etc.). For any class, a number of constructor functions may be declared,each taking different types of arguments, providing different ways of initializinginstances. A default constructor for a class is a constructor ofthat class that can be called without any arguments. A default constructorfor a class will be automatically generated if no constructor has beenexplicitly declared for that class. A copy constructor for a classis a constructor that can be called to copy an object of that class (ithas a single argument of the corresponding type). A copy constructor iscalled when, for example, an argument object is passed by value to a function,or when an object is initialized with the value of another object. A copyconstructor for a class will be automatically generated if no copy constructorhas been explicitly declared for that class. A member function with thesame name as the class with a leading tilde (~) is a destructor.This is a function that is called automatically when the object is deleted.The destructor is typically used to deallocate any memory allocated forthe object (and may also release any other resources acquired during construction).Constructors and destructors are not required in class definitions.
There are several ways to create objects in a C++ program. One is todefine a variable as being of a particular class, either as a global variableor as a local variable within a block. When the declaration is encounteredduring program execution, space is allocated for the object and the constructor,if any, for the object is called. Similarly, when an object variable goesout of scope, its destructor is called automatically. Another way to createan object is to declare a variable that is a pointer to the object classand call the C++ new operator, which will allocatespace for the object and call the constructor, if any, for the object.In this case, the pointer variable must be explicitly deallocated withthe delete operator. The constructor for theobject is executed when new is called, andthe destructor is executed when delete is called.An object can also be constructed by the explicit use of a constructorin an expression.
When a class is derived from another class, it inherits its parent class'constructor and destructor. Parent constructors are invoked before derivedconstructors. Destructors are invoked in the opposite direction, proceedingfrom the derived class upward through its parent chain.
OOCOBOL
The life-cycle for an object begins when it is created, and ends whenit is destroyed. An object of a given class is created using a CBL-CREATEmethod associated with the class object for that class. Object classesmay be defined as transient, persistent, or collectable.If a class is transient, the class objects and objects of the classare destroyed automatically when the run unit (program execution) terminates.If a class is persistent, the class object and objects of the classare destroyed only when a CBL-DISCARD method is invoked on them. Persistentclass objects and persistent objects exist from one run unit to the next.If a class is collectable, the class is transient and hence theclass objects and objects of the class are destroyed automatically whenthe run unit terminates. In addition, objects of the class may be destroyedbefore the run unit terminates by the run unit's garbage collector, whenthey can no longer be referenced by transient objects within the run unit.(If a reference to a transient object is stored in the object data or classobject data of a persistent object, the results of using this referenceare undefined).
Smalltalk
Smalltalk object instances are created with the "new" method.Each object instance is given a unique identifier called an object pointeror object reference. New classes are created by using the "subclass"method. The "new" and "subclass" methods are inheritedby almost all classes. Every instance object pointer is also associatedwith an object pointer of a class. Unlike the "new" and "subclass"methods, there are no specific methods that remove an object that is nolonger useful. Smalltalk objects are deleted when they are no longer reachable(garbage collected).
Eiffel
The lifetime of an object in Eiffel extends from creation until it becomesunreachable. i.e., an object exists when it is created and attached tosome entity; it ceases to exist when either it has lost all referencesto it (and so becomes unreachable) or it is explicitly `forgotten' (deleted).An unreachable object is automatically garbage collected.
To make a new object in Eiffel the create construct is used ("!!")whereby a new object is created and attached to an entity, such as an attribute.During creation all simple types (integers, reals, strings, charactersand references) are initialized to default values.
Removing or forgetting an object is performed by either losing all referencesto an object or by attaching the special object Void to the entity. Forexample,
a := Void
Supposing there are no other references to the object initially attachedto a, then that object has been forgotten.
An object generally exists no longer than the lifetime of the executingprogram. However, the lifetimes of objects can be extended through theuse of persistence. A number of library classes supply the necessary functionalityfor objects to become persistent and therefore exist beyond the lifetimeof the program.
Emerald
See 6. Identity, Equality, Copy
Cecil
New objects are created either through object declarations, orby evaluating object constructor expressions. An object declarationhas the form:
object <name> {<relation>}[ <field_inits> ]
where <relation>denotes isa, inherits,or subtypes specificationsdescribing the parents and/or supertypes (respectively) of the new object.The form of an object constructor expression is the same except that noname is specified. Object constructor expressions are analogous to objectcreation operations found in class-based languages. Note that only fieldsare specified in object constructors; methods are defined in separate expressionsto allow them to be associated with multiple objects through their specializers(see entry under 2.5 methods). Objects are garbage collected whenthey are no longer referenced by other objects.
SELF
To make a new object in SELF, an existing object (called the prototype)is cloned (shallow-copied). The slots in the new object that correspondto state variables (including parent slots) can then be set to instance-specificvalues. An addition, the structure of the new object can be changed byadding or deleting slots, using special language primitives. As in Smalltalk,objects exist as long as there are references to them from other objects(SELF supports garbage collection).
System Object Model (SOM)
SOM objects are created by invoking a create operation on a factoryobject in the SOM run time. Once created, the object will exist until explicitlydeleted or until the process that created it no longer exists. A SOM objectwould need to make use of a persistence mechanism in order to exist beyondthe life of the process that created it. A persistence mechanism is beyondthe scope of this object model discussion, however, SOM could be and hasbeen used as the basis for building a variety of persistence frameworks.
OLE Component Object Model
Unlike C++, where objects are constructed using the class's constructorfunction, there are a number of ways to create a Windows Object. A commonway is to use a class factory object. A class factory object representsa specific class identifier, is obtained by a specific OLE function, andsupports an interface named IClassFactory. The IClassFactoryinterface contains a function named CreateInstance, to which ispassed an identifier of the desired interface to that object. The expressionIClassFactory::CreateInstance is the logical equivalent of C++'snew.
In C++, an object is destroyed by calling the delete operatoron an object pointer (which ultimately causes the object's destructor functionto be called). The corresponding function that frees a Windows Object (andessentially calls its destructor) is a function called Release.This function is part of the IUnknown interface, and is thus presentin every interface. However, calling Release does not necessarilydestroy the object. Internally, the object maintains a count of how manyreferences exist to any of its interfaces. Creating an interface pointerincrements the reference count, whereas Release decrements it. Whenthe count is reduced to zero, the object frees itself, calling its owndestructor.
Analysis and Design Methods
SA: The lifetime of an instance is explicitin the state diagram of the class. Each class either has a "circular"life cycle and instances always exist, or has a "born and die"life cycle and instances are created and destroyed as a result of events.
CA: Create and release services are implicitin all classes. Release disconnects any existing message connections anddeletes the instance.
RA: No explicit concept of instance lifecycle.
RC: "Objects [instances] can beallocated statically (at compile time), dynamically (from a heap), or ona stack." The lifetime of static objects "is the duration ofthe program." "Most temporary and intermediate objects will beimplemented as stack-based... The advantage is that they are automaticallyallocated and deallocated... [when] the declaring block [is] exited.""One allocated, dynamic objects persist until they are explicitlydeallocated. ... Some languages ... provide garbage collection, which removesthe burden of deallocation from the programmer..."
JA: "When a class in instantiated,a instance is created that follows a path in [a state transition graph]throughout its lifetime." [i have not yet found the discussion ofthe end of the lifetime, though this is implicit in the correlation ofuse case instances with instances of control objects.]
WD: Instance lifetime is discussed asa language issue.
MD: Objects are explicitly created; theyexist until they are no longer referenced.
EA: The special interaction, "[c]reatebrings an object into existence within the analysis system being modeled."The special interaction, "[d]estroy causes an existing object to ceaseto exist as far as the analysis model is concerned."
FA: "The keyword new preceding anobject identifier [in the Changes clause of an operation model schema]indicates that the system operation creates a new object in the systemstate."
FC: "An important issue... is thatof object destruction." This issue is treated as language dependent.
OA: "In a creation event an entirelynew object appears." "[E]ach time an object is created, is mustbecome a member of some object type's set." "In a terminationevent, an object is removed from our awareness." "[A]fter terminationthe object is no longer an instance of any object type."
BD: Object lifetime is determined inaccordance with the possibilities provided by the implementation language.
HA: No explicit concept. Objectchartsshow initial and final states.
NA: Discussed as an implementation issuein terms of the possibility of garbage collection as a language capability,and the necessity in any case of providing for the eventual destructionof persistent objects.features matrixintro page