Skip to main content

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

What is the lowest granularity we can re-use without modifying? Steps or
sub-sequences?
I would think steps are. Sub-sequences can be thought as a logical and
convenient grouping of steps.

Just for example:

- Sub-sequence "InstantiateService", includes "serviceTracker",
"gdbBackend", "controlService", "processService" steps.
- Sub-sequence "gdbSpecific", includes "gdbInit", "gdbWorkingDirectory"
steps.
- Sub-sequence "executableSpecific", includes "executableAndSymbol",
"augumentToExecutable", "environmentToExecutable" steps

And so on.

Most likely "gdbSpecific" sub-sequence will not fit many adaptors so
they will re-define it, but the "gdbInit" and "gdbWorkingDirectory"
steps will likely be more generic so we will re-use.

- Andy

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Pawel Piech
Sent: July 8, 2010 1:15 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility

On 07/08/2010 09:42 AM, Vladimir Prus wrote:
> On Thursday 08 July 2010 20:09:41 Mikhail Khodjaiants wrote:
>    
>> The proposed solution defines the step order as API which means that 
>> adding/removing/reordering steps can be done only for the major
releases.
>>      
> 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,
>    
This is why I like the sub-sequence approach.  It allows the super-class
to define a new level of API for the steps, i.e. grouping of steps them
into logical sets.  The custom sub-class can compose the complete final
launch sequence using the sub-sequences while leaving the flexibility in
the base class to change the ordering within the sub-sequences.  It's
been pointed out that sub-classes may need to modify the sub-sequences
themselves also.  I think that's OK, because it would be a clear choice
for the deriving class: a) re-use a sub-sequence as is and benefit from
its evolution, b) replace or extend a sub-sequence and deal with
maintenance costs associated with that.

Cheers,
Pawel
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top