At 09:42 23/4/01 +0200, Leo Simons wrote:
>I'm working on updating the docs (yay for me =).
>Please stay away from em...
>
>Several things popped up while updating the lifecycle
>docs...
>
>1 - Executable and Interruptable are in the proposal, but
>haven't appeared in the main tree yet. Is this something
>you haven't got around to yet, Pete, or is it not gonna
>happen anymore?
no idea - I would -1 the Executable name in favour of something else
(Animatable or Active???). Still can't think of a good name for
Interruptable thou ;)
>2 - init() has not been changed to initialize() yet...will
>this change?
Charles vetoed it and I have got around to challengine it yet - until that
happens we can't change it ;)
>3 - the Re<XXX> interfaces should all be updated to
>extend Interruptable:
>
>Reconfigurable extends Configurable, Interruptable
>Recontextualizable extends Contextualizable, Interruptable
>Recomposable extends Composable, Interruptable
I need to think about that and look how I use Re* in my code.
>4 - if we keep Parameters (and I believe no-one has a problem
>with that), the next logical step would be to also define
>
>interface Reparameterizable extends Parameterizable, Interruptable {
>
> public void reparameterize( Parameters parameters ) throws
>ParameterException;
>
>}
Possibly - though not sure it is needed - I guess thats a lets talk about
it point ;)
>5 - it is currently stated that start(), run() and stop() may be
>called multiple times. I have a problem with that - some Components
>may not support this behaviour (I don't think they should), while
>some containers may require it. The replacement would be the use
>of Commands.
>A compromise might be to deprecate the repeated use of these methods
>and provide commands as the alternative - gives Pete until v5 to
>update to the new setup =)
-1 on adding commands at this stage
+1 at fixing docs
Need more thought about start/stop only callable once - I wouldn't have
problem with changing to this behaviour I don't think.
>6 - The proposal was to add a Commandable and a Command instead (they're
>in the proposal dir), and make sure the mentioned methods are
>called only once.
>If we do that, I think getCommands() would go after start()/run()
>and before anything else, that all returned Commands are guaranteed
>to start() (as new threads) before any other method is called,
>and that a Component is responsible for suspend()ing and resume()ing
>Commands if that is neccessary.
>Also, Command threads will run until finished, even if a Component
>has already been dispose()d of. A container may choose to stop them
>if they do not finish in a timely manner (the Component is once
>again responsible for making sure that happens in stop() and/or
>dispose()). Command threads will always be stopped and dereferenced
>before a Component is dereferenced though (so finalize() on the
>Component can take care of any last loose ends).
>So:
>
>...
>comp.start()
>comp.run()
>cmds = comp.getCommands()
>runAll(cmds)
>comp.suspend()
>comp.resume()
>comp.suspend()
>comp.resume()
>cmds.stop()
>cmds.dispose()
>...
>
>while(! exit ) {
> stopAll(cmds)
> cmds = null;
> comp = null;
> System.gc(); // finalize() called on comp
>}
>
>can I have votes/comments on 1-6 where neccessary?
-1 because untested and late. It is similar to a lot of task based systems
that written or are involved in (Ant - yaya!) or are in frameworks (such as
ACE or concurrent from that smart guy). However we need testing.
>PS: what I'm doing with the docs? Two things. The first
>one is changing all the language and some of the
>organisation so things are easier to follow (you guys
>have a 'nack for using complicated terms =), the second
>is updating the docs to reflect recent changes.
kewl. Most likely all the inverted sentances were mine - I was a
philosophy/logic student for waaaay too long ;)
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
