----- Original Message -----
From: Claudio Valderrama C. <cvalde@...>
To: <IB-Architect@egroups.com>
Sent: Friday, June 02, 2000 2:20 AM
Subject: RE: [IB-Architect] New API: Object Life Time
> > 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?
There can be to meanings to close, as I see it:
a. in reference to a connection specifically, all ties to the server should
be severed, but all internal state should be kept (to which server we were
connection, though which port, any other details)
b. if you really want to free all context, calling close() should be the
same as deleting the object and creating a new one; anything less is not
true uninitialization.
To me, the word "close" means something closer to (a) than to (b). Opinions
on this, anyone?
> > 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?
If the internal count is zero, then the object has already been destroyed.
Any references to an object should be discarded after a call to release() -
or, more correctly, calls to addref() and release() should be balanced;
after your last release, you should never again reference the object.