Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

I have another idea.
How about make FinalLaunchSequence an API where all steps "execute"
methods defined as protected methods with certain prefix.
The steps initialization function would form steps array by taking all
method of a current FinalLaunchSequence  class (which could be
overriden)
and instantiate  a Step classes with a method name as a parameter.
Order would be determined by method name. Execute function would call
a method using reflection.

Example:

protected void step_01_fetchGdbBackendService() {...}
...
protected void step_04_loadGdbInitFile(){...}

Client would override this and
1) to change step - override it
2) to remove step - override and make empty
3) to add step (for example between 3 and 4) add a method

protected void step_03_1_establishConnection(){...}


Old cut & paste method would work too..


Now comments regarding "we never will able be fix it again":
a) For cdt implementation we can make another class that extends FLS
which is not an API - so we can do whatever we want there
b) We can add methods/steps in minor revision change releases
c) In maintenance release if we need to add a step (hell of bug fix)
we can always add private method, and make it protected later

step class for this would look like
FStep extends Step{
    FStep(String executeMethod) {
        this.method = excuteMethod;
    }
     public void execute(RequestMonitor requestMonitor) {
        call_method(method, requestMonitor);
    }
}

and
void protected initializeSteps
{
    String[] method = getSortedMethods();
    fSteps = new Steps[method.length];
    for (i=0;i<method.length;i++) {
       fSteps[i]=new FStep(method);
    }
}

On Fri, Jul 9, 2010 at 8:51 AM, Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx> wrote:
> On Thursday 08 July 2010 23:35:04 Mikhail Khodjaiants wrote:
>
>> On 08/07/2010 2:54 PM, Marc Khouzam wrote:
>> >> -----Original Message-----
>> >> From: cdt-dev-bounces@xxxxxxxxxxx
>> >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
>> >> Sent: Thursday, July 08, 2010 2:27 PM
>> >> To: cdt-dev@xxxxxxxxxxx
>> >> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
>> >>
>> >> On 08/07/2010 2:04 PM, Marc Khouzam wrote:
>> >>
>> >>> That is interesting.  It's like the subSequence solution, with
>> >>> each subSequence being a single step.  How would you define the
>> >>> step ids?
>> >>>
>> >>>
>> >> Yes, that's correct. See the Andy Jin's comment regarding granularity.
>> >> I was thinking of the traditional Eclipse style strings:
>> >> <plugin_id>.steps.gdbinit, for instance.
>> >>
>> > Thinking about it some more, isn't this very much like Vladimir's early
>> > suggestion:
>> >
>> >> - Add protected members for each step of FinalLaunchSequence, e.g.:
>> >>
>> >>    protected Step getTrackerStep = new Step() { .... } ;
>> >>
>> >> - Add factory methods, e.g.:
>> >>
>> >>      protected Step getTrackerStep() { .... }
>> >>
>> It is similar. But the difference is to have a steps library outside of
>> FinalLaunchSequence.
>
> For the record, I don't care much whether the standard steps are defined as protected
> methods inside FinalLaunchSequence or as standalone classes, or as factory
> functions. If the name of step does not include the index of the step, then
> all those solutions have pretty much the same properties:
>
> - A predefined step may not be removed without breaking API
> - An order change in FinalLaunchSequence will not be automatically
> picked by derived classes.
>
> I, personally, can live with both those restrictions -- as soon as my launch sequence
> can cleanly reuse standard steps.
>
> I think that using string identifiers as indices into some hash, as opposed as Java-level
> compile-time identifiers is much more brittle, though.
>
>
> Thanks,
>
> --
> Vladimir Prus
> CodeSourcery
> vladimir@xxxxxxxxxxxxxxxx
> (650) 331-3385 x722
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>