2 Nov
2011
2 Nov
'11
9:18 a.m.
Yes it does seem strange, and it took me a while to accept it.
The point is that, in Java, you can have different methods with the same name and
different parameters.
So, without a clear handle on the type of all parameters, you cannot decide for sure that
a method call is the same as a method declaration.
Another point is that JDT is made to work in an IDE, with incomplete code.
That's why, even with the source declaration of the method, JDT does not link it to
its calls unless it could resolve all the parameters' types.
That's why it is also important to have all the needed libraries when parsing with
verveineJ
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Cc: codesite-noreply(a)google.com
Envoyé: Mardi 1 Novembre 2011 11:07:26
Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ places methods in the
wrong classes
Thanks. Indeed, it is strange. Btw, I am on a Mac OS X Lion.
I will try again and get back to you later.
But, coming back to the issue, the goal of the script is to provide a
set of possible methods that are misplaced (that is methods that
should appear in another class than where they are actually defined).
The issue is that if we have the source for the class, it means we
should have parsed it and have the proper information about its
methods. So, how could then methods appear inside without source code?
Cheers,
Doru
On 1 Nov 2011, at 10:35, Nicolas Anquetil wrote:
what I did:
- download ArgoUML-0.32-src.tar.gz (sources of ArgoUML) from the web
site you gave
- download ArgoUML-0.32-libs.tar.gz (libraries needed by ArgoUML)
from the web site you gave
- update verveinej to get your new shell script
- rm -f output.mse
- create MSE file:"verveinej.sh -autocp ArgoUML-0.32-libs
ArgoUML-0.32-src"
- load MSE in Moose panel
- ran your script in workspace
When calling verveineJ, "-autocp ArgoUML-0.32-libs" is important.
Without it, JDT is not able to resolve a lot of types names, and as
a consequence, a lot of source methods that use these types (e.g. as
parameter type).
And without JDT's name resolution, verveineJ is not able to link a
method call to a method declaration.
With the autocp, I found 13 methods with problems.
Without it, I found 473 (or something like that) methods with
problems.
Not your 575 ones, but closer to it.
No idea how we can get so different results with the same data and
program !!!
nicolas
----- Mail original -----
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: moose-technology(a)googlecode.com
À: moose-dev(a)iam.unibe.ch
Envoyé: Mardi 1 Novembre 2011 07:40:20
Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ
places methods in the wrong classes
Updates:
Status: Started
Comment #7 on issue 728 by tudor.gi...(a)gmail.com: VerveineJ places
methods
in the wrong classes
http://code.google.com/p/moose-technology/issues/detail?id=728
Hmm, I just tried. First, I fixed the shell script (verveinej.sh)
to
collect the jars automatically from the lib folder. Then I removed
the
obsolete jars.
But, still, if I run the following experiment, I get 575
potentially
problematic methods:
- download ArgoUML 0.32 from:
http://argouml-downloads.tigris.org/argouml-0.32/
- parse, load in Moose, and then execute:
(MooseModel root allModels first allMethods select: [:each |
each sourceAnchor isNil and: [
each parentType sourceAnchor notNil and: [
'<Initializer>' ~= each name and: [
each name ~= each parentType name ]]]]) openInMoose
Am I doing something wrong?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev