[
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 Vladimir Prus
> Sent: Thursday, July 08, 2010 12:43 PM
> To: Mikhail Khodjaiants
> Cc: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
>
> On Thursday 08 July 2010 20:09:41 Mikhail Khodjaiants wrote:
>
> > On 08/07/2010 6:31 AM, Vladimir Prus wrote:
> > > 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,
> > >
> > >
> >
> > 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.
Not if FinalLaunchSequence is copied by each integrator instead of
extended. I know no-one likes that, but we cannot make
FinalLaunchSequence an API or else we will never be able to change
it, which is bad for DSF-GDB.
That is why I thought the sub sequence idea may give us a better
solution.
> 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,
>
> --
> Vladimir Prus
> CodeSourcery
> vladimir@xxxxxxxxxxxxxxxx
> (650) 331-3385 x722
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
