Stephen wrote:
> Daniel Frey wrote:
>> Niclas wrote:
>>> On Monday 15 March 2004 16:51, Stephen McConnell wrote:
>>>> Niclas Hedhman wrote:
>>>>> On Monday 15 March 2004 16:23, Daniel Frey wrote:
>>>>>
>>>>>> Thanks Alex for the example. Nice code! I see there that the main
>>>>>> frame is generated within the execute method, an approach that I was
>>>>>> taking, but was not sure about.
>>>>>
>>>>> Since I know my own agenda, I recommend that you use the Startable
>>>>> interface instead... I think there will be consensus to remove
>>>>> Executable in Framework 5.0, since the Startable can do the same job.
>>>>
>>>> I think this subject will raise a bit of debate. Startable is a
>>>> non-blocking operation whereas Executable is in-line execution. As
>>>> such, you can correlated Initializable and Executable much more closely
>>>> that Executable and Startable.
>>>
>>> Not sure what you mean by "non-blocking", since there are no differences
>>> between the two in Merlin. Both will result in a activation timeout if
>>> not
>>
>>
>>> returning. The only difference, AFAICT, is that the component author
>>> need to replace
>>>
>>> public void execute()
>>>
>>> with
>>>
>>> public void stop() { }
>>> public void start()
>>
>>
>> Why is execute() replaced with stop() and start()?
>
> It's not - but its a subject that will come up over on the dev list.
>
>> I don't understand the logic behind it.
>
> If you look at the lifecycle contract as documented in A4, the container
> is responsible for taking the component through a complete deployment
> phase before exposing the reference to other components.
Where do I find A4 (I don't know what it is, but seems to be important for
my understanding)?
> This means that there is no difference between a component the puts
> execute semantics inside an initialize method as opposed to a component
> that puts execution semantics inside a execute method. As such one can ask
> the question "what is the purpose and logic of Executable".
>
> In practice the purpose and logic appears to make sense in non-lifecycle
> scenarios (such as action objects, gui apps, etc.). My own opinion is
> that Executable represents a common and useful abstraction but its an
> abstraction that should not be part of the lifecycle.
>
> But this thread is getting way into [EMAIL PROTECTED] territory!
> Cheers, Stephen.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
