[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
On 07/07/2010 4:17 PM, Marc Khouzam 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.
Marc
+1
I think it's a good idea. But don't expect it to be the final solution -
some clients may want to customize subsequences :)
