[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
This somewhat dovetails into my discussion about launch extensibility.
Your collection of debuggers is just a subset of all the different
debuggers we need to support. I'd like to see a fully extensible
mechanism for this, and one easy for integrators to do.
On Wed, Jul 7, 2010 at 7:51 AM, Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> because our product happens to support a lot of different debuggers,
> including somewhat tricky ones, we've added a custom final launch
> sequence that seriously modifies a couple of steps. The
> remaining dozen and a half steps from standard FinalLaunchSequence
> are perfectly OK, and we would like to reuse it, but it turns out
> problematic. All the steps are defined like so:
>
> private Step[] fSteps = {
> new Step() { .... } ;
> }
>
> So, even if I derive a class from FinalLaunchSequence, I cannot even access
> any of the standard steps. Further, even if fSteps were private, accessing
> predefined steps by index would be very brittle. Another approach is to
> just copy-paste FinalLaunchConfiguration, but this is obviously not a
> sound engineering.
>
> Two solutions that would work are:
>
> - Add protected members for each step of FinalLaunchSequence, e.g.:
>
> protected Step getTrackerStep = new Step() { .... } ;
>
> - Add factory methods, e.g.:
>
> protected Step getTrackerStep() { .... }
>
> Then, both FinalLaunchSequence and derived classes can build a sequence
> of steps easily.
>
> Comments?
>
> In fact, the above solution still has a problem -- if the order of steps
> in FinalLaunchSequence ever changes, the derived classes have to be
> updated too, and it's not easy to detect this case. I'd actually prefer
> if names of members/methods be prefixed with the index of the step, e.g.
> '_1_getTrackerStep', so that should order change (and members renamed to match),
> the derived classes will stop compiling.
>
> Comments? I'll be willing to work on a patch, provided there's definite agreement
> on the acceptable direction.
>
> 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
>
