Hi Abeer,
Please look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=326951.
Some of the issues you mentioned are solved there. You can modify
that patch to include your suggestions.
Thanks,
Mikhail
On 10/02/2011 6:25 AM, Abeer Bagul wrote:
Hi,
In our DSF launch, I create a subclass of GDBLaunch using the
method GdbLaunchDelegate.getLaunch(). Currently this method does
the following steps:
1) Create an object of GDBLaunch
2) Initialize the above obj
3) Create the sourceLocator
3.1) Initialize the sourceLocator from the memento
The method getSourceLocator() is also private, so a subclass of
GDBLaunchDelegate, which only wants to substitute the GDBLaunch
object and the sourcelocator object, while keeping the superclass
initialization sequence as it is, has to currently copy both the
methods getLaunch() and getSourceLocator() to the subclass. If
there is any minor bugfix to the initialization sequence in these
methods in the superclass, the vendor specific subclass will miss
out on these bug fixes.
Can we modify the GDBLaunchDelegate as follows:
1) Make getSourceLocator() protected instead of private
2) Create the GDBLaunch object in a separate protected method
createLaunch() which is called from getLaunch() in place of the
constructor call.
3) Create the sourceLocator object in a separate protected method
createSourceLocator which is called from getSourceLocator in place
of the constructor call.
Have attached a patch to GDBLaunchDelegate to demonstrate the
changes.
Thanks
Abeer Bagul.
Tensilica India.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|