// // Drop -- end existence of an object // @deftype Drop - getZone; - (void) drop; @end
Every object supporting drop must also retain an internal reference to the zone from which its storage was allocated. The Drop supertype provides access to this original allocation zone using the getZone message. If an object was created by a create: message, the zone returned is the same zone passed as an argument to create:.
Immediate effects of the drop message depends on the subtype of Zone used to provide storage for the object. For some zone types, the drop message immediately deallocates storage for the object and makes the freed storage available for other use. Subsequent use could include the allocation of a new object at precisely the same location, resulting in a new object id identical to a previously dropped one. Other zone types (..none implemented yet..) might delay any reclamation of freed storage until a more comprehensive check can be made that other references no longer exist to the dropped object. When running in debug mode (see debug support) the storage for a dropped object is filled with predictable contents so that an error is raised if there is any immediate attempt to us it again.
The Drop type may be inherited by any type that provides drop support for its instances. In addition to freeing the storage and invalidating the object, a drop message may release other resources acquired or held within the object. Not every object which can be created can also be dropped, and some objects can be dropped which are not directly creatable. Some objects may be created as a side effect of other operations and still be droppable, and some objects may be created with links to other objects and not droppable on their own. A type independently inherits Create or Drop types, or both, to indicate its support of these standard interfaces to define the endpoints of an object lifecycle.