Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
I more like an idea to have step ID and linked hash map that holds the steps.
Because as soon as we do sub sequence user would want to change steps in it,
and we are back to square one. BTW we run into problem with
FinalLaunchSequence as soon as we
start porting to DSF and end up copying this whole thing, so I really
would like to have it
addressed one way or another.
On Wed, Jul 7, 2010 at 4:17 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
> This is an interesting discussion about a problem that really needs
> to be addressed. FinalLaunchSequence is a problem for inheritance
> for its first creation. I personally did not find a elegant way to
> make it easily overridable. But with more and more people using it,
> it would be nice to find a good way to handle this problem.
> I think the fundamental problem we are dealing with here is what
> overriding classes want to do with FinalLaunchSequence. Classes
> that override it seem to want to
> 1- add steps anywhere
> 2- remove certain steps
> 3- re-use as much as FinalLaunchSequence as possible to get
> bug fixes automatically
> This seems pretty demanding :-)
> As it was pointed out, a change in ordering of steps in the base class
> could cause problems to overriding classes. However, such a change
> may also be something a deriving class wants to get, while other
> deriving class may not.
> To me, it makes re-using the actual _functionality_ of
> FinalLaunchSequence very difficult as it is right now.
> There are good suggestions on how to make it more overridable,
> but I get the feeling that all these solutions will require
> FinalLaunchSequence to remain as is with respects to its Steps,
> to avoid breaking potential overriding classes. This is very
> limiting for DSF-GDB and will surely force us to override
> FinalLaunchSequence ourselves.
> Maybe a better approach would be to first split FinalLaunchSequence
> into multiple sub-sequences that would perform a somewhat
> modular piece of work. Maybe a subSeq to deal with 'attach'
> sessions, another subSeq for 'remote' sessions, one for
> loading the binary and its parameters, etc.
> An overriding class could then pick and choose which set
> of Steps it wants to re-use and which ones it wants to change.
> It could add new sub sequences and remove others.
> A subsequence would have to be modular enough that changes
> made to it as bug fixes in the base class would most probably
> be good changes for an overriding class. For example, fixing
> a bug in how the IP address is read for remote debugging should
> be propagated to overriding classes.
> I hadn't really thought about such a solution before, so I'd
> like to know what you guys think.
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx
>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
>> Sent: Wednesday, July 07, 2010 12:54 PM
>> To: CDT General developers list.
>> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
>> On 07/07/2010 09:30 AM, Vladimir Prus wrote:
>> > 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
>> Final launch sequence is probably the most advanced sequence
>> out there
>> so its testing the limits of the API. Still, extensibility
>> is something
>> that is likely to be applicable to other use cases of
>> sequence so I don'
>> t mind creating a general solution. Of course, you could
>> just as well
>> create a FinalLaunchSequcneStep abstract class or interfaces, or use
>> some other option that was suggested, but I wanted to point out that
>> adding to the base Sequence class is also on the table :-)
>> > 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
>> The down side of the factory approach is that it restricts
>> the evolution
>> in the base class, but OTOH it makes the derived classes more
>> I don't know what's more important here.
>> cdt-dev mailing list
> cdt-dev mailing list