28 Oct
2010
28 Oct
'10
1:38 p.m.
Hi,
thanks Doru for the detailed review.
I did some of the easy things.
The thing is like this:
1. either you produce namespaces like moose.lan.server that do not belong to other
namespaces
2. or you create nested namespaces that have simple names (like lan) that belong to other
namespaces (like moose)
Right now, you do a combination of 1 and 2, which does
not produce proper results. inFusion does 1, but actually we almost always infer the
namespace nesting in Moose, so it would be best if the parser would produce 2.
The goal would also be to compare the amount and
quality of the produced entities. I went quickly through the LAN example, and here is what
I found:
(+) Inner classes are exported as nested to the parent class
(+) Anonymous classes are exported as nested in the parent method
(+) namespaces are nested
(+) Implicit variables like self and super
(+) receiver variables properly set in invocations
(-) VerveineJ does not produce annotation instances
and annotation types.
I put this in the wish list of the project
(-) No exceptions
I put this in the wish list
(-) classes like <Primitive Package>::void
should be PrimitiveTypes
Yes I know :-(
I was lazy
(-) namespace should have simple names
done
(-) References seem to be at the level of namespaces
and it is unclear where they come from (it looks like they come from the nesting which
should not be modeled as a reference)
They come from the "import" statements ...
Never was sure if it was a good idea or not, but I though it could be
nice to have the info ...
(-) There are no source anchors
OK, I did it for Classes, Methods and Attributes.
I left out method parameters, implicit variables, local variables and
associations.
I am afraid that would result in a huge model ...
Actually it was implemented at some point for invocations for
debugging purposes but then I commented it out :-)
(-) There are no primitive metrics like lines of code,
cyclomatic complexity, number of statements
It is already in the wish list
(-) There are no entities marked as stub (for example
java.lang.Object is not stub)
There could be some entities marked as stub.
The point is JDT binding resolver is quite good (it is used as a
compiler front end after all)
So, if one specifies correctly the source path and class path and all,
we have precisely all the information on all the entities.
For example, this means we can find the attributes and methods of
classes that are not in the parsed source code, but in libraries.
Currently, the stub flag is only set when we don't have this
information (which means, a library or something was not properly
specified in the command line).
Apart from this VerveineJ fetches all the informations "upward": It
fetchs the container of the entities, and for classes their superclass
(recursively)
Two persons already told me that the stub should be for everything
that is not in the parsed source code, even if we have all the info on
it.
You are the third one.
When we reach the total of 741 people asking for it, I will put it in
the wish list :-)
OK, I will think about it, actually it should not be too difficult
(-) Interfaces are exported as regular FAMIXClass (it
would be better to have them as FAMIXInterface, or at least to have the isInterface flag
set to true)
Yes I know
Did I mention I am lazy ?
"Implements" and "inherits" are both translated as
"Famix.Inheritance", I guess?
(-) The signature of the methods have an unwanted
space between the name and the parentheses
This one was easy, I can do it any time
(*) It would be cool to also have the next and
previous values set for the associations (this would be useful to recover the order in
which instructions appear in the code)
wish list
I will have to think a bit about it
So this is it for today
I will be looking at the other ones in the coming days (hopefully)
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod