Skip to main content

[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[]{
				new Step() {...}

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.


The proposed solution defines the step order as API which means that adding/removing/reordering steps can be done only for the major releases.

Back to the top