Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

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