[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
On Thursday 08 July 2010 01:09:18 Mikhail Khodjaiants wrote:
> > Maybe a better approach would be to first split FinalLaunchSequence
> > into multiple sub-sequences that would perform a somewhat
> > modular piece of work. Maybe a subSeq to deal with 'attach'
> > sessions, another subSeq for 'remote' sessions, one for
> > loading the binary and its parameters, etc.
> >
> > An overriding class could then pick and choose which set
> > of Steps it wants to re-use and which ones it wants to change.
> > It could add new sub sequences and remove others.
> >
> > A subsequence would have to be modular enough that changes
> > made to it as bug fixes in the base class would most probably
> > be good changes for an overriding class. For example, fixing
> > a bug in how the IP address is read for remote debugging should
> > be propagated to overriding classes.
> >
> > I hadn't really thought about such a solution before, so I'd
> > like to know what you guys think.
> +1
> I think it's a good idea. But don't expect it to be the final solution -
> some clients may want to customize subsequences :)
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,
--
Vladimir Prus
CodeSourcery
vladimir@xxxxxxxxxxxxxxxx
(650) 331-3385 x722