Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] [DSF] CommandFactory_6_8


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.
- create a new MIVariableManager version, as you pointed out
- 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.



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?

cdt-dev mailing list

Back to the top