Actually, this observation applies not just for invocations to stub methods, but for
any kind of invocations.

Let's take the invocation example:
aMethod(a, b()), where a and b() are of types A and B, respectively

Right now, even if we know the method, we get as a signature aMethod(A, B). This information
is essentially not useful, because we already have the definition of the method and
its parameters.

So, even in this case, we would still benefit from having aMethod(a, b()) as a signature
because it provides extra information.

Fixed first issue (andrehoraa). Please check this is what was needed.

For 2nd comment (tudor) I am not sure I understand.
The signature of the method is its name and the type of its parameters, it is independant
of the different calls one can make.
Please clarify

We are talking about the signature of an invocation, not of a method. This should be
the text corresponding to the call, and not a duplicate of the signature of the method.

OK, never noticed that invocations had signature  :-)

Will have to look at it

Nicolas, my issue is fixed. Thanks :)


I understood what Doru is saying. But consider the invocation #setElements in a source
code:

setElements(Model.getModelManagementHelper()
                    .getAllModelElementsOfKindWithModel(model,
                            Model.getMetaTypes().getTagDefinition()));

Do we want to see in the MSE exactly the signature above or the code below?

setElements(?)

I believe the second one is also relevant.
Maybe we can have both? Something like #signature and #realSignature?

@Andre: I do not understand. If you get the signature of the stub method, why is it
important to have setElements(?)?

Just because it is simpler to read and more important because when it is not stub you
can see the type of the parameters ex: setElements(String)

I do not understand. Why do you need to read the signature of an invocation? And why
is it not enough to have the "setElements(String)" signature in the called method?

As I said, just because I think it is simpler, clearer, and you easily see the number
of parameters and the types (when not stub) from such invocation. But yes, you can
also check it from the #candidates methods if you have them.
And yes, see the full invocation like you said is nice too as it provides extra information
(but not easily the number of parameters and the types :)

How did you fix this?

As you asked in email #1

Great!