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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Thursday 08 July 2010 23:35:04 Mikhail Khodjaiants wrote:

> On 08/07/2010 2:54 PM, Marc Khouzam wrote:
> >> -----Original Message-----
> >> From: cdt-dev-bounces@xxxxxxxxxxx
> >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> >> Sent: Thursday, July 08, 2010 2:27 PM
> >> To: cdt-dev@xxxxxxxxxxx
> >> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
> >>
> >> On 08/07/2010 2:04 PM, Marc Khouzam wrote:
> >>      
> >>> That is interesting.  It's like the subSequence solution, with
> >>> each subSequence being a single step.  How would you define the
> >>> step ids?
> >>>
> >>>        
> >> Yes, that's correct. See the Andy Jin's comment regarding granularity.
> >> I was thinking of the traditional Eclipse style strings:
> >> <plugin_id>.steps.gdbinit, for instance.
> >>      
> > Thinking about it some more, isn't this very much like Vladimir's early
> > suggestion:
> >    
> >> - Add protected members for each step of FinalLaunchSequence, e.g.:
> >>
> >> 	protected Step getTrackerStep = new Step() { .... } ;
> >>
> >> - Add factory methods, e.g.:
> >>
> >>      protected Step getTrackerStep() { .... }
> >>      
> It is similar. But the difference is to have a steps library outside of 
> FinalLaunchSequence.

For the record, I don't care much whether the standard steps are defined as protected
methods inside FinalLaunchSequence or as standalone classes, or as factory
functions. If the name of step does not include the index of the step, then
all those solutions have pretty much the same properties:

- A predefined step may not be removed without breaking API
- An order change in FinalLaunchSequence will not be automatically
picked by derived classes.

I, personally, can live with both those restrictions -- as soon as my launch sequence
can cleanly reuse standard steps.

I think that using string identifiers as indices into some hash, as opposed as Java-level
compile-time identifiers is much more brittle, though.


Thanks,

-- 
Vladimir Prus
CodeSourcery
vladimir@xxxxxxxxxxxxxxxx
(650) 331-3385 x722