[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
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.
Cheers,
Pawel
On 07/07/2010 08:55 AM, Dave Korn wrote:
On 07/07/2010 12:51, Vladimir Prus wrote:
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.
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.
cheers,
DaveK
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
