Skip to main content

[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.


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.


cdt-dev mailing list

Back to the top