[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
On Wednesday 07 July 2010 20:00:05 Pawel Piech wrote:
> 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.
Does 'step id' have a meaning outside FinalLaunchSequence and derived
classes? If not, it's probably best to not expose this concept to
everybody, rather using some mechanisms local to FinalLaunchSequence.
> On 07/07/2010 08:55 AM, Dave Korn wrote:
> >> 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.
But, what happens if a step disappears, or order changes. It seems like you'll
get a runtime error, while a compile error is somewhat more convenient.
Thanks,
--
Vladimir Prus
CodeSourcery
vladimir@xxxxxxxxxxxxxxxx
(650) 331-3385 x722