> -----Original Message-----
> 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.

Would be fine to publish the first approach in the web, or was it done
already?

> After
> 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.

Seem fine and you can do whatever you want in the implementation. Trying to
avoid delete operator?

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

As long as it has some coherency with the specification you are trying to
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 to
> deletion.

I can't agree more, of course.

> 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.

It's an interesting approach. Since I cannot communicate with a server if
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 to
> prevent memory leaks but only to control memory usage.

As long as the parent keeps control in the Delphi way (owner means taking
care of children), we will avoid a BDE-II. :-)

> I will also redefine release() to return the post release use
> count of the object. A return of zero means the object is history.

This is common practice in several libraries. What happen if release() is
called when the internal count is zero? Exception? Undefined?

> A client that wants to force release must loop decrementing the
> use count to zero.

Can I mix close() and release(), then? AFAIK, after calling close(), the
component is almost gone, so the release() work is decrementing the counter
mainly.

> 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.

Seems nice, the problem is when I happen to mix calls, so I threw a bunch
of questions above.

> Comments? Questions? Bickering? Seconds may call at 40 Beach St.,
> Manchester, MA, during normal programmer hours...
>
> Jim Starkey

No, sorry, an international call is not cheap for me, so I prefer email.

C.