finalization order?

Alejandro F. Reimondo aleReimondo at smalltalking.net
Thu Jan 8 14:51:33 UTC 2004


Hi Ragnar,
If you have dependencies on time, it is recommended to use encapsulation to
define explicity a coordinator for internal parts of an engine (an
instanciation of a framework).
The coordinator/engine (one object) is used to manage time dependency and
behavior of internal parts and has the responsibility of ensuring it's
stalility.
When an object "understand" a mesage they doit during all it's life...
 one of the indicators for refactoring is the dependence on time.
Each time you find time dependencies it is recommended to define a framework
and not make the parts/organs responsible of the main engine/body.
If you are wrapping a library where the functions are time dependent (poor
design but very common in the industry) it is better to model the time
dependency in a kind of "manager"/controller/coordinator. If you do not do
this kind of modeling, the (implisit) constrain will be hidden and a naive
user will be surprised when he/she is not already prepared to explore the
problem.

> I don't think I can practically do that in the general case, because
> heres the chain of objects that are created when, say, a search is
> requested through LDAPConnection.
>
>    LDAPAsyncOperation / LDAPSearchOperation  -> LDAPSearchResults ->
>    LDAPEntry -> LDAPAttributeIterator

See all the steps as been realized by an engine that must be
 instantiated (instantiation of a framework) to make some work.
The engine (as a coordinator) can be finalized
 and then release all it's resources.

Dependence on time must be solved with encapsulation.
If you can´t define an object with the responsibility
 of engine stability:
1.- your sub-system is architecturally inestable (and can be
 modeled as a family of engines)
2.- you must wait to find it (emergence of a model).

In case of (1) the nature of the system is dynamic and you
 can´t ensure stability in all the posible conditions/instantiations
 (don't worry atomic bombs are not used :-)

In case of (2) be patient.

Constraining the finalization schema to have the same order
 of instance creation is not an option (e.g. you can use the
 same instance many times...)

with best regards,
Ale.


----- Original Message -----
From: "Ragnar Hojland Espinosa" <ragnar at linalco.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, January 08, 2004 10:30 AM
Subject: Re: finalization order?


> On Thu, Jan 08, 2004 at 10:03:28AM -0300, Alejandro F. Reimondo wrote:
> > Try to make only the connection (not the handle) to be finalized.
> > Consider the handle as a private instance of the connection (it's
owner).
>
> I don't think I can practically do that in the general case, because
> heres the chain of objects that are created when, say, a search is
> requested through LDAPConnection.
>
>    LDAPAsyncOperation / LDAPSearchOperation  -> LDAPSearchResults ->
>    LDAPEntry -> LDAPAttributeIterator
>
> and each of these classes needs in-order finalization or I end up with
> a connection being teared down but the thread still going on..
>
> > ----- Original Message -----
> > From: "Ragnar Hojland Espinosa" <ragnar at linalco.com>
> >
> > > I have the equivalent of the following:
> > >
> > >    handle _ MyHandle new.
> > >    conn _ MyConnection newUsing: handle
> > >
> > > When handle and conn are GCed, I was expecting first for conn to be
> > > finalized and then for handle.  Thats happens almost all the time but
> > > not always, which is quite inadecuate.. can I do something about it?
>
> --
> Ragnar Hojland - Project Manager
> Linalco "Specialists in Linux and Free Software"
> http://www.linalco.com  Tel: +34-91-4561700
>




More information about the Squeak-dev mailing list