Re: [cdt-dev] [DSF] CommandFactory_6_8

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Hi,

The CommandFactory is meant to modify simple parameters of an existing MI command. You cannot add a new MI command.
In fact, adding a new MI command implies new functionality for a specific GDB version, which cannot be handled through
the command factory.

getFeatures does not help with much.  For example, we created CommandFactory_6_8 to use pendingBreakpoints in MI,
but the -list-features of GDB reports that this feature is available much before 6_8, no?

Here is what I suggest:
- depending on the complexity of the change, you can put it in MIVariableManager directly, as long as the class continues to
work for all versions of GDB.
or
- create a new MIVariableManager version, as you pointed out
or
- add the new command to CommandFactory and have it return nul, override it in CFactory_6_8l.  Make sure to check for null 
whenever you use this method and have a alternative path if you do get null.  This would be setting a precedent in how we use
CommandFactory, so I'd have to see how it looks before promising that such a solution will be accepted.

Thanks

Marc

________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vladimir Prus [vladimir@xxxxxxxxxxxxxxxx]
Sent: October 2, 2010 4:54 AM
To: CDT General developers list.
Subject: [cdt-dev] [DSF] CommandFactory_6_8

I was working on some patch that requires a command not yet supported by
CommandFactory_*, and Mikhail has pointed out that I might want to add
it to CommandFactory_6_8, not CommandFactory.

That sounded like a good idea, but then I need to make use of the command
inside MIVariableManager -- which only has CommandFactory reference. Of
course, I can add MIVariableManager_6_8, but this seems like a slippery slope.
Classes are relatively high-conceptual-overhead objects, while an extra
GDB command is relatively small implementation detail. Therefore, it seems
not too good idea if we end up with a lot of Whatever_6_8, Whatever_7_0,
Whatever_7_2, etc classes, just because one method in Whatever can make
use of a new command.

Would it be better instead of make of use new IGDBControl.getFeatures()
instead to conditionalize behaviour as much as possible, and have a single
CommandFactory instead?

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