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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin
> Sent: Thursday, July 08, 2010 1:58 PM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] [DSF] FinalLaunchSequence extensibility
> 
> What is the lowest granularity we can re-use without 
> modifying? Steps or
> sub-sequences?
> I would think steps are. Sub-sequences can be thought as a logical and
> convenient grouping of steps.

I'm not sure what you mean.
We can override a step, but we'll need to put the infrastructure
to do so first.

> 
> Just for example:
> 
> - Sub-sequence "InstantiateService", includes "serviceTracker",
> "gdbBackend", "controlService", "processService" steps.
> - Sub-sequence "gdbSpecific", includes "gdbInit", 
> "gdbWorkingDirectory"
> steps.
> - Sub-sequence "executableSpecific", includes "executableAndSymbol",
> "augumentToExecutable", "environmentToExecutable" steps
> 
> And so on.

That is an encouraging example.  Seems to help.

> Most likely "gdbSpecific" sub-sequence will not fit many adaptors so
> they will re-define it, but the "gdbInit" and "gdbWorkingDirectory"
> steps will likely be more generic so we will re-use.
> 
> - Andy
> 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Pawel Piech
> Sent: July 8, 2010 1:15 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
> 
> On 07/08/2010 09:42 AM, Vladimir Prus wrote:
> > On Thursday 08 July 2010 20:09:41 Mikhail Khodjaiants wrote:
> >    
> >> 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,
> >    
> This is why I like the sub-sequence approach.  It allows the 
> super-class
> to define a new level of API for the steps, i.e. grouping of 
> steps them
> into logical sets.  The custom sub-class can compose the 
> complete final
> launch sequence using the sub-sequences while leaving the 
> flexibility in
> the base class to change the ordering within the sub-sequences.  It's
> been pointed out that sub-classes may need to modify the sub-sequences
> themselves also.  I think that's OK, because it would be a 
> clear choice
> for the deriving class: a) re-use a sub-sequence as is and 
> benefit from
> its evolution, b) replace or extend a sub-sequence and deal with
> maintenance costs associated with that.
> 
> Cheers,
> Pawel
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>