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

[Anna Dushistova <anna_dushistova@xxxxxxxxxx>]

On Jul 8, 2010, at 12:17 AM, Marc Khouzam wrote:

> This is an interesting discussion about a problem that really needs
> to be addressed.  FinalLaunchSequence is a problem for inheritance
> for its first creation.  I personally did not find a elegant way to 
> make it easily overridable.  But with more and more people using it,
> it would be nice to find a good way to handle this problem.
> 
> I think the fundamental problem we are dealing with here is what
> overriding classes want to do with FinalLaunchSequence.  Classes 
> that override it seem to want to 
> 1- add steps anywhere
> 2- remove certain steps
> 3- re-use as much as FinalLaunchSequence as possible to get
>   bug fixes automatically
> 
> This seems pretty demanding :-)
> 
> As it was pointed out, a change in ordering of steps in the base class
> could cause problems to overriding classes.  However, such a change
> may also be something a deriving class wants to get, while other 
> deriving class may not.
> 
> To me, it makes re-using the actual _functionality_ of 
> FinalLaunchSequence very difficult as it is right now.
> 
> There are good suggestions on how to make it more overridable,
> but I get the feeling that all these solutions will require
> FinalLaunchSequence to remain as is with respects to its Steps,
> to avoid breaking potential overriding classes.  This is very
> limiting for DSF-GDB and will surely force us to override
> FinalLaunchSequence ourselves.
> 
> 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.

I like this idea, makes sense to me.

Anna.