Re: [cdt-dev] Allow a subclass of GDBLaunchDelegate to create its own La

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

All patches should go through bugzilla

On Thu, Feb 10, 2011 at 6:26 AM, Abeer Bagul <abeer4eclipse@xxxxxxxxx> wrote:
> Hi,
>
> Sorry, forgot to attach the patch in the earlier mail.
>
> Thanks
> Abeer Bagul
> Tensilica India.
>
> On Thu, Feb 10, 2011 at 4:55 PM, Abeer Bagul <abeer4eclipse@xxxxxxxxx>
> 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
>
>