Subject Re: [IB-Architect] New API: Object Life Time
Author Glebas Paulevicius

>Object life times are managed with addRef() and release(). When
>the use count (decremented by release()) goes to zero, the object
>joins the great bit bucket in the sky.

addRef - decRef, attach - detach, ... - release

>The method close(), when present, can be used to release any context
>or resources associated with the object but without deleting the

flush() is better in such context.

>All objects are automatically closed, if necessary, prior to


>A parent object, when deleted, takes its children with it. Releasing
>a PreparedStatement would automatically delete all ResultSets. Releasing
>a Connection object would delete everything associated with the connection.

Good if you are still determined to bother with pointers and deleting them
I still vote for any destructive action to be placed in destructor
(in a place for destructive actions to take place)

>Releases (other than the Connection object) are not necessary to
>prevent memory leaks but only to control memory usage.


>I will also redefine release() to return the post release use
>count of the object. A return of zero means the object is history.
>A client that wants to force release must loop decrementing the
>use count to zero.

Oops! This will violate the other client's rights to the object!
What is the reason for client to want to force the delete?

>For example, the Connection object is allocated, unconnected, by
>createConnection() then activated by openDatabase(). Connection::close()
>would close the connection, freeing the Connection object for another
>connection. Connection::release() (assuming no intervening addRef()s)
>would close the connection and delete the object.

Jim, I have something deep inside me against having
Connection object in "unconnected" mode!
The fact that Connection object is created should
MEAN - we are connected!
Please, avoid object modes if possible.