|Subject||RE: [IB-Architect] New API: Object Life Time|
|Author||Claudio Valderrama C.|
> -----Original Message-----Would be fine to publish the first approach in the web, or was it done
> From: Jim Starkey [mailto:jas@...]
> Sent: Jueves 1 de Junio de 2000 17:07
> The last draft of the specification had somewhat of a muddle
> over object lifetime. Some classes had a close(), others had
> addRef() and release(), and some lucky ones had both.
> AfterSeem fine and you can do whatever you want in the implementation. Trying to
> pondering the issue, I've got a proposal:
> 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.
avoid delete operator?
> The method close(), when present, can be used to release any contextAs long as it has some coherency with the specification you are trying to
> or resources associated with the object but without deleting the
follow, it seems acceptable. However, the term "context or resources" is a
bit blurry for me. What would be left after a close() call? The "skeleton"
of the object, only the static part of its structure? What happens after
that with a method call? An exception?
> All objects are automatically closed, if necessary, prior toI can't agree more, of course.
> A parent object, when deleted, takes its children with it. ReleasingIt's an interesting approach. Since I cannot communicate with a server if
> a PreparedStatement would automatically delete all ResultSets. Releasing
> a Connection object would delete everything associated with the
the Connection object is destroyed and I cannot use a resultset that comes
from a prepared statement that's being unprepared, seems logical. Does
close() get rid of the children objects, too?
I see some objects are the parent of others. Nice hierarchy, but try to not
give it too many levels. Even if I don't give MS papers too much importance,
I put my eyes in this paragraph:
DAO and RDO, the object models that preceded ADO, are highly hierarchical
models. To return results from a data source, the programmer has to start at
the top of the object model and traverse down to the layer that contains the
recordset. The ADO object model is not hierarchical.
> Releases (other than the Connection object) are not necessary toAs long as the parent keeps control in the Delphi way (owner means taking
> prevent memory leaks but only to control memory usage.
care of children), we will avoid a BDE-II. :-)
> I will also redefine release() to return the post release useThis is common practice in several libraries. What happen if release() is
> count of the object. A return of zero means the object is history.
called when the internal count is zero? Exception? Undefined?
> A client that wants to force release must loop decrementing theCan I mix close() and release(), then? AFAIK, after calling close(), the
> use count to zero.
component is almost gone, so the release() work is decrementing the counter
> For example, the Connection object is allocated, unconnected, bySeems nice, the problem is when I happen to mix calls, so I threw a bunch
> 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.
of questions above.
> Comments? Questions? Bickering? Seconds may call at 40 Beach St.,No, sorry, an international call is not cheap for me, so I prefer email.
> Manchester, MA, during normal programmer hours...
> Jim Starkey