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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

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