Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] [DSF] FinalLaunchSequence extensibility


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> Sent: Thursday, July 08, 2010 1:10 PM
> To: Vladimir Prus
> Cc: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
> On 08/07/2010 12:42 PM, Vladimir Prus wrote:
> >
> > This is only technically correct, in that any other 
> solution will also
> > require care when modifying the sequence. Suppose there's 
> hash map from
> > ids to Step instances. Then, if a step is removed in a 
> minor release,
> > derived classes will break. Likewise, for order changes. 
> So, it suggests
> > that the sequence of steps is actually part of API for 
> derived classes.
> >
> > Thanks,
> >
> >    
> I don't know how the hash map solution is supposed to work. If that's 
> the case then it shouldn't be accepted.
> I am proposing to have a set of Steps with id defined outside of 
> FinalLaunchSequence to allow clients to write their own 
> FinalLaunchSequences combining predefined steps. 

That is interesting.  It's like the subSequence solution, with
each subSequence being a single step.  How would you define the
step ids?

> I am very skeptical 
> that we can come up with a universal FinalLaunchSequence 
> class for all  use cases. 

I completely agree.

> Even the current one is already difficult to 
> follow with all the session types, attributes, etc.

It really was meant for DSF-GDB as is.

> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top