Status: New Owner: ---- CC: anquetil...@gmail.com Labels: Type-Enhancement Priority-Medium Component-VerveineJ Milestone-4.7
New issue 880 by andreho...@gmail.com: 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.
Comment #1 on issue 880 by tu...@tudorgirba.com: 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.
Updates: Status: Fixed
Comment #2 on issue 880 by anquetil...@gmail.com: 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
Comment #3 on issue 880 by tu...@tudorgirba.com: 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.
Updates: Status: Accepted
Comment #4 on issue 880 by anquetil...@gmail.com: 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
Comment #5 on issue 880 by andreho...@gmail.com: 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?
Comment #6 on issue 880 by tu...@tudorgirba.com: 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(?)?
Comment #7 on issue 880 by andreho...@gmail.com: 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)
Comment #8 on issue 880 by tu...@tudorgirba.com: 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?
Comment #9 on issue 880 by andreho...@gmail.com: 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 :)
Updates: Labels: -Milestone-4.7 Milestone-4.8
Comment #10 on issue 880 by tu...@tudorgirba.com: Improving VerveineJ stub invocations/methods http://code.google.com/p/moose-technology/issues/detail?id=880
(No comment was entered for this change.)
Updates: Status: Fixed
Comment #11 on issue 880 by anquetil...@gmail.com: Improving VerveineJ stub invocations/methods http://code.google.com/p/moose-technology/issues/detail?id=880
(No comment was entered for this change.)
Comment #12 on issue 880 by tu...@tudorgirba.com: Improving VerveineJ stub invocations/methods http://code.google.com/p/moose-technology/issues/detail?id=880
How did you fix this?
Comment #13 on issue 880 by anquetil...@gmail.com: Improving VerveineJ stub invocations/methods http://code.google.com/p/moose-technology/issues/detail?id=880
As you asked in email #1
Updates: Labels: -Milestone-4.8 Milestone-4.7
Comment #14 on issue 880 by tu...@tudorgirba.com: Improving VerveineJ stub invocations/methods http://code.google.com/p/moose-technology/issues/detail?id=880
Great!
-
moose-technology＠googlecode.com