[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
> -----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
>