Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 241985

Summary: [services] Service factory should be used to create ICommandControl
Product: [Tools] CDT Reporter: Marc Khouzam <marc.khouzam>
Component: cdt-debug-dsfAssignee: Pawel Piech <pawel.1.piech>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: cdtdoug, dd.general-inbox, pawel.1.piech
Version: 0 DD 1.1Flags: cdtdoug: iplog-
Target Milestone: DD 1.1   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
First part of fix
cdtdoug: iplog-
Ugly solution that works
cdtdoug: iplog-
Cleanup of GDBControl constructor
cdtdoug: iplog-
Use of variable number of arguments cdtdoug: iplog-

Description Marc Khouzam CLA 2008-07-24 11:58:53 EDT
Service factory should be used to create the command control, even though the interface itself is not a service.

Also, the service factory should not use abstract methods in AbstractDsfDebugServicesFactory because it forces to implement them all.  Instead, all these methods should be protected and return null. This will be better for debuggers that don't support all these services.

Finally, ISymbols and ISignals should also be part of the factory.
Comment 1 Marc Khouzam CLA 2008-07-24 12:18:37 EDT
Created attachment 108369 [details]
First part of fix

This patch removes the abstract from the methods, and adds ICommandControl, ISignals and ISymbols.  It also uses alphabetical order to make it easier to know if something is forgotten.

Committed.
Comment 2 Marc Khouzam CLA 2008-07-27 15:11:42 EDT
Created attachment 108506 [details]
Ugly solution that works

I now remember why I hadn't put the ICommandControl service as part of the service factory.  It was because the constructor to GDBControl took a bunch of parameters, unlike all the other services.

This solution makes the GDBControl constructor the same as all the other ones, and add set...() methods for all the other missing parameters.  I don't like it much.

Any better suggestions?

Also, I left the old constructor and deprecated it.  Then I realized this was a provisional class, so I'm thinking I can remove that constructor completely, yes?

Committed (but if a better solution is suggested, I'll change it with pleasure)
Comment 3 Marc Khouzam CLA 2008-07-28 12:59:32 EDT
(In reply to comment #2)
Pawel wrote this comment in another bug by mistake:
"That's indeed rather ugly :-(.  Another option may be to just pass the launch
configuration in a single set...() call, then let GDBControl extract the
parameters as needed.  This may create some code duplication, but maybe not."
Comment 4 Marc Khouzam CLA 2008-07-29 14:07:44 EDT
Created attachment 108679 [details]
Cleanup of GDBControl constructor

(In reply to comment #3)
> (In reply to comment #2)
> Pawel wrote this comment in another bug by mistake:
> "That's indeed rather ugly :-(.  Another option may be to just pass the launch
> configuration in a single set...() call, then let GDBControl extract the
> parameters as needed.  This may create some code duplication, but maybe not."

Actually, it turned out to be quite clean.  Thanks for the idea.

I had another idea.  I'll attach a patch to illustrate.
Comment 5 Marc Khouzam CLA 2008-07-29 14:37:05 EDT
Created attachment 108683 [details]
Use of variable number of arguments

The service factory only allows to pass a single parameter to the service when creating it.  This patch adds a variable list of parameters to the signature of createService().  It allows any number of parameters to be passed to a service.  This can prove useful for future service versions.

The problem is that you loose some compile-time checks on the parameters.  However, this is relatively isolated, so I don't think it is a risk.

Opinions?
Comment 6 Pawel Piech CLA 2008-07-29 15:24:08 EDT
(In reply to comment #5)
> Opinions?
I don't see how it would cause any harm, so +1 from me.
Comment 7 Marc Khouzam CLA 2008-07-29 15:55:47 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > Opinions?
> I don't see how it would cause any harm, so +1 from me.

Great.  I re-ordered the parameters to have the name of the class first and then all parameters, including the session and I committed.

Pawel, can you verify?
Comment 8 Pawel Piech CLA 2008-07-31 00:39:34 EDT
Reviewed.
Comment 9 Pawel Piech CLA 2009-01-07 16:03:03 EST
DD 1.1 reelased!