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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Thursday 08 July 2010 20:09:41 Mikhail Khodjaiants wrote:

> 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.

This is only technically correct, in that any other solution will also
require care when modifying the sequence. Suppose there's hash map from
ids to Step instances. Then, if a step is removed in a minor release,
derived classes will break. Likewise, for order changes. So, it suggests
that the sequence of steps is actually part of API for derived classes.

Thanks,

-- 
Vladimir Prus
CodeSourcery
vladimir@xxxxxxxxxxxxxxxx
(650) 331-3385 x722