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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

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.

Marc
 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
> Sent: Wednesday, July 07, 2010 12:54 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
> 
> On 07/07/2010 09:30 AM, Vladimir Prus wrote:
> > On Wednesday 07 July 2010 20:00:05 Pawel Piech wrote:
> >    
> >> Another option would be to add a a Step.getID() method which would
> >> return an optional identifier for the step (Step is an 
> abstract class so
> >> this would be a backward compatible change). The deriving 
> class could
> >> override Sequence.getSteps() and insert its own steps into 
> the sequence
> >> in front of or after a step with a known ID.  getSteps() 
> is called many
> >> times, but it's assumed to be static, so the deriving 
> class can safely
> >> call the super-class once and then cache the modified array.
> >>      
> > Does 'step id' have a meaning outside FinalLaunchSequence 
> and derived
> > classes? If not, it's probably best to not expose this concept to
> > everybody, rather using some mechanisms local to 
> FinalLaunchSequence.
> >
> >    
> Final launch sequence is probably the most advanced sequence 
> out there 
> so its testing the limits of the API.  Still, extensibility 
> is something 
> that is likely to be applicable to other use cases of 
> sequence so I don' 
> t mind creating a general solution.  Of course, you could 
> just as well 
> create a FinalLaunchSequcneStep abstract class or interfaces, or use 
> some other option that was suggested, but I wanted to point out that 
> adding to the base Sequence class is also on the table :-)
> > Unless perhaps the (private) array were replaced by a (protected) 
> > hash, with
> >>> well-known names for the keys and the steps themselves as 
> the values.  (This
> >>> would need to be combined with a separate array to hold 
> the ordering of the
> >>> steps.)  It would then I think be quite robust to derive 
> classes that could
> >>> refer to the standard steps known to be defined in a 
> parent, and could modify
> >>> the inherited ordering or substitute its own altogether.
> >>>        
> > But, what happens if a step disappears, or order changes. 
> It seems like you'll
> > get a runtime error, while a compile error is somewhat more 
> convenient.
> >    
> The down side of the factory approach is that it restricts 
> the evolution 
> in the base class, but OTOH it makes the derived classes more 
> reliable.  
> I don't know what's more important here.
> 
> Cheers,
> Pawel
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>