You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/04/21 05:36:31 UTC

[Framework] Dualities in Activity methods

Hi,

Theres a few concerns I have relating to the activity related lifecycle
methods and changes proposed recently. It was identified that there is no
real need to separate suspend/resume features. They were effectivly a dual
that were codependent. It was then further identified that start/stop was a
dual and *should* be codependent. Further more suspend/resume requires
start/stop.

Taking this one step further we would see that Initialize/Dispose are a
dual aswell and by the same token should be kept together. There could be
also an arguement that start/stop *should* extend initialize/dispose.

thus we have

interface ID 
{ 
 initialize();
 dispose();
}

interface SS extends ID
{
 start();
 stop();
}

interface SR extends SS
{
 suspend();
 resume();
}

This is what is the "proper" way of doing things. I had a look through my
own code, avalons code and other codebases (ie turbine) and found that most
of the code did not follow this pattern. So naturally I feel a little
uncomfortable at changing our pattern at the eleventh hour before we got
beta when it has yet to be tested.

I also don't really like the proposed name. I already use Executable in
another interface name as do a few other projects (most likely ant aswell).
The Blahable name is also an accepted pattern for interfaces with a single
method blah() - I don't think we should change that. Possible alternatives
I could think of were

Constructed - the Initializable/Disposable dual
Active, Animated - the Startable/Stoppable dual
ReBuilder??? - the suspend/resume dual

Then I began thinking ... do we even need suspend/resume? What does
suspend/resume give us that start/stop doesn't give us? 

start/stop could be called multiple times in lifecycle of component, only
while stopped could you recontextualize/recompose/reconfigure. So what do
you think - do we need suspend/resume?

Fede also expressed some reservations about the package name
"org.apache.avalon.lifecycle" so I propose the name
"org.apache.avalon.activity".

Thoughts?





Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: [Framework] Dualities in Activity methods

Posted by Peter Donald <do...@apache.org>.
At 09:01  23/4/01 -0400, Berin Loritsch wrote:
>Peter Donald wrote:
>> 
>> Hi,
>> 
>> Taking this one step further we would see that Initialize/Dispose are a
>> dual aswell and by the same token should be kept together. There could be
>> also an arguement that start/stop *should* extend initialize/dispose.
>
>They are a natural pair.  However this does not mean they are codependant.
>When two interfaces are bound to each other it usually means using them
>separately can lead to dangerous coding practices or even difficult to
>track bugs.
>
>The idea of Initializable interface is that by contract the Component has
>received all of its Configuration, Context, ComponentManager, etc. abjects.
>At this point, it is safe for the Component to create new Components and
>pass any of the lifecycle Component objects.  Not every Component needs this
>complexity, and right after Configuration it is ready to go.
>
>Conversely, the Disposable interface is by contract the last part of the
>lifecycle before the Component is readied for the garbage collector.  It
>is important to note that Disposable isn't just for propogating the
>dispose() message to all child Components, but that it can be used for
>general cleanup.  Hense, there are many uses where Initializable isn't
>needed, but Disposable is.
>
>I beleive that by keeping these two interfaces separate and distinct
(although
>a natural pair) is more beneficial than harmful.

okay. Then tomorrow I will move into activity package. I will remove
startable/stoppable and replace them with Active (or Animated???). Can
anyone think of a similar non -able name for the suspend/resume pair ?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: [Framework] Dualities in Activity methods

Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> 
> Hi,
> 
> Taking this one step further we would see that Initialize/Dispose are a
> dual aswell and by the same token should be kept together. There could be
> also an arguement that start/stop *should* extend initialize/dispose.

They are a natural pair.  However this does not mean they are codependant.
When two interfaces are bound to each other it usually means using them
separately can lead to dangerous coding practices or even difficult to
track bugs.

The idea of Initializable interface is that by contract the Component has
received all of its Configuration, Context, ComponentManager, etc. abjects.
At this point, it is safe for the Component to create new Components and
pass any of the lifecycle Component objects.  Not every Component needs this
complexity, and right after Configuration it is ready to go.

Conversely, the Disposable interface is by contract the last part of the
lifecycle before the Component is readied for the garbage collector.  It
is important to note that Disposable isn't just for propogating the
dispose() message to all child Components, but that it can be used for
general cleanup.  Hense, there are many uses where Initializable isn't
needed, but Disposable is.

I beleive that by keeping these two interfaces separate and distinct (although
a natural pair) is more beneficial than harmful.

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


RE: [Framework] Dualities in Activity methods

Posted by Stephen McConnell <mc...@osm.net>.
On the need for suspend/resume
------------------------------
Our usage of start/stop versus  start/stop is quite different.  We use
'start' to invoke startup of an  ORB and stop to shutdown the orb.  Our
implementation uses suspend/resume as points where ORB traffic can be
suspended, but the active ORB is still valid.  This condition enables the
establishment of a quasi-stable environment under which some administrative
actions can be performed in the knowledge that the number of in-memory
components is stable.

On the question of binding together init/dispose
------------------------------------------------
During the discussion and messages exchanged about the lifecycle operations
I looked into the pairing question concerning init/dispose.  While in
principal this looked like a match, our code provided a different story.  In
our code there is a high usage of the Dispose interface - basically we use
this as the general cleanup operation to dispose of an in-memory slots etc.
A sub-set of this code uses a much wider set of lifecycle operations
together with an extension of Disposable called Vulnerable - which is an
interface which deals with disposal of a persistent object identity (with
operations 'expendable' and 'terminate').  Even in the case of Vulnerable
interface we found that there was not a need to pair this with the init
operation because the majority of our objects are constructed through
factories that return fully initialized objects.

Cheers, Steve.


> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Saturday, 21 April, 2001 05:37
> To: avalon-dev@jakarta.apache.org
> Subject: [Framework] Dualities in Activity methods
>
>
> Hi,
>
> Theres a few concerns I have relating to the activity related lifecycle
> methods and changes proposed recently. It was identified that there is no
> real need to separate suspend/resume features. They were effectivly a dual
> that were codependent. It was then further identified that
> start/stop was a
> dual and *should* be codependent. Further more suspend/resume requires
> start/stop.
>
> Taking this one step further we would see that Initialize/Dispose are a
> dual aswell and by the same token should be kept together. There could be
> also an arguement that start/stop *should* extend initialize/dispose.
>
> thus we have
>
> interface ID
> {
>  initialize();
>  dispose();
> }
>
> interface SS extends ID
> {
>  start();
>  stop();
> }
>
> interface SR extends SS
> {
>  suspend();
>  resume();
> }
>
> This is what is the "proper" way of doing things. I had a look through my
> own code, avalons code and other codebases (ie turbine) and found
> that most
> of the code did not follow this pattern. So naturally I feel a little
> uncomfortable at changing our pattern at the eleventh hour before we got
> beta when it has yet to be tested.
>
> I also don't really like the proposed name. I already use Executable in
> another interface name as do a few other projects (most likely
> ant aswell).
> The Blahable name is also an accepted pattern for interfaces with a single
> method blah() - I don't think we should change that. Possible alternatives
> I could think of were
>
> Constructed - the Initializable/Disposable dual
> Active, Animated - the Startable/Stoppable dual
> ReBuilder??? - the suspend/resume dual
>
> Then I began thinking ... do we even need suspend/resume? What does
> suspend/resume give us that start/stop doesn't give us?
>
> start/stop could be called multiple times in lifecycle of component, only
> while stopped could you recontextualize/recompose/reconfigure. So what do
> you think - do we need suspend/resume?
>
> Fede also expressed some reservations about the package name
> "org.apache.avalon.lifecycle" so I propose the name
> "org.apache.avalon.activity".
>
> Thoughts?
>
>
>
>
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org