[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] The role oforg.eclipse.cdt.debug.mi.core.command.CommandFactory
|
Norbert,
The way it is currently there is not much harm since the CommandFactory
does not do anything very deep behind the scenes. This could become an
issue if creating a command in the factory becomes connected with deeper
activities (e.g. keeping track of all commands created and processed).
There are no plans currently to use CommnadFactory for the type of
activities you mentioned, but I can't promise that it will never happen.
In this case merely "extending" the class will not help me because I
must create my commands from the right factory _instance_.
I'm not sure that I get it right. You create your own CommandFactory
instance and pass it to the session. Your instance will be used by the
session.
Mikhail
----- Original Message -----
From: "Ploett, Norbert" <norbert.ploett@xxxxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Thursday, December 08, 2005 1:50 AM
Subject: AW: [cdt-dev] The role
oforg.eclipse.cdt.debug.mi.core.command.CommandFactory
Mikhail,
the problem I have is this:
- The CommandFactory is used throughout CDT to create commands.
- Now I invent a new command im my own, separate plug-in.
- I could, of course, "extend" (in the Java sense) CommandFactory to
MyCommandFactory and add another create(...) method, but this would mean
that "the rest of the world" is still using the old CommandFactory.
The way it is currently there is not much harm since the CommandFactory
does not do anything very deep behind the scenes. This could become an
issue if creating a command in the factory becomes connected with deeper
activities (e.g. keeping track of all commands created and processed).
In this case merely "extending" the class will not help me because I
must create my commands from the right factory _instance_.
But I don't know whether there are any plans in that direction.
And probably the extension point you talked about will fix this anyway.
What do you think?
Norbert
-----Ursprüngliche Nachricht-----
Von: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Mikhail Khodjaiants
Gesendet: Dienstag, 6. Dezember 2005 20:04
An: CDT General developers list.
Betreff: Re: [cdt-dev] The role
oforg.eclipse.cdt.debug.mi.core.command.CommandFactory
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
