[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
On 08/07/2010 6:31 AM, Vladimir Prus wrote:
Right. Not to mention that even if FinalLaunchSequence actually composes
several other sequences, I still want a derived classes to both:
- Easily replace something, and
- Fail to compile if FinalLaunchSequence adds a new step
So, can we first figure how to derive a class from a DSF-provided
sequence of steps and customize the steps in a way that is robust
in face of future changes.
To be more concrete, the approach I propose is:
class DsfStandardSequence extends Sequence
{
protected _1_doInitialMagic = new Step() { ... }
protected _2_doMoreMagic = new Step() { ... }
private Step[] fSteps = null;
public final Step[] getSteps() {
if (fSteps == null)
fSteps = getStepsReally();
return fSteps;
}
protected Step[] getStepsReally()
{
return new Step[]{_1_doInitialMagic, _2_doMoreMagic};
}
}
class CustomSequence extends DsfStandardSequence
{
protected Step[] getStepsReally()
{
return new Step[]{
_1_doInitialMagic,
new Step() {...}
_2_doMoreMagic,
};
}
This approach has the advantage that:
1. The derive class can replace, remove or add steps in the simplest
way possible.
2. If a base step is removed, or reordered, you get compile error.
The disadvantage is that a new step added in base won't be noticed.
This can be fixed by making getStepsReally return a list, and then:
class CustomSequence extends DsfStandardSequence
{
protected List<Step> getStepsReally()
{
List<Step> s = super.getStepsReally();
s.add(s.indexOf(_2_doMoreMagic, new Step());
return s;
}
}
This is similar to using ids. The big disadvantage here is that
the complete sequence is not explicitly written out, so getting
a high-level picture is hard.
Thanks,
The proposed solution defines the step order as API which means that
adding/removing/reordering steps can be done only for the major releases.