Issue 880 in moose-technology: Improving VerveineJ stub invocations/methods

Status: New
Owner: ----
CC: [hidden email]
Labels: Type-Enhancement Priority-Medium Component-VerveineJ Milestone-4.7

New issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

When creating models without classpath, invocations/methods (where the  
biding are not found) are created in the format:

anInvocation(???)

This is the case even if the real invocation in source code contains  
parameters such as:

anInvocation(a, b)

It would be good maintain the information with respect to the number of  
parameters in such invocation/method, and then export the #signature with  
something like:

anInvocation(?, ?)

Like that we can at least count the number of parameters.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #1 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Fixed

Comment #2 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #3 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Accepted

Comment #4 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

OK, never noticed that invocations had signature  :-)

Will have to look at it

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #5 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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?





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #6 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #7 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #8 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #9 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

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 :)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Labels: -Milestone-4.7 Milestone-4.8

Comment #10 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

(No comment was entered for this change.)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Fixed

Comment #11 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

(No comment was entered for this change.)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #12 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

How did you fix this?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #13 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

As you asked in email #1

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Labels: -Milestone-4.8 Milestone-4.7

Comment #14 on issue 880 by [hidden email]: Improving VerveineJ stub  
invocations/methods
http://code.google.com/p/moose-technology/issues/detail?id=880

Great!

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev