Re: [cdt-dev] The role of org.eclipse.cdt.debug.mi.core.command.CommandF

["Mikhail Khodjaiants" <mikhailk@xxxxxxx>]

Norbert,

What kind of problems do you have extending the CommandFactory class?
CommandFactory was introduced to allow the replacement of the standard 
gdb/mi command set. There are plans to add an extension point for command 
factory contributions. This will include also the extension of the standard 
gdb/mi command set.
Of course, you can add your commands without extending the CommandFactory 
class. But please create a bugzilla entry with the description of the 
problem you are seeing.

Thanks,
Mikhail
----- Original Message ----- 
From: "Ploett, Norbert" <norbert.ploett@xxxxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Tuesday, December 06, 2005 2:22 AM
Subject: [cdt-dev] The role of 
org.eclipse.cdt.debug.mi.core.command.CommandFactory


> Hello MI debugging folks,
>
> while implementing a new CLICommand / MIInfo pair (see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=119370
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=119370>  for details) I
> came across the fact that all the existing commands are created from
> methods of the above mentioned CommandFactory class. This is a scheme I
> found difficult to extend (without modifying the classes' code ...).
>
> On the other hand I found that the methods themselves were not doing
> anything more than calling new for the individual Command (o.k., and
> holding the MI version).
>
> So I just created my CLICommand using new directly, without using the
> factory. But I feel a little uneasy about leaving the factory aside. Did
> I overlook anything? Will the factory become more important in the
> future? In this case it should be extensible so that additional commands
> can be contributed from other plug-ins.
>
> How is that?
>
> Thanks,
>
>
> Norbert