29 Oct
2010
29 Oct
'10
1:11 p.m.
Hi,
Great work. I looked over the changes in the LAN model. I list some issues below.
If you give me your Google account, I can add you to the Google Code page of Moose and we
can handle the issues via this tracker.
Great.
That is exactly what we need.
However, you are storing the absolute path. The problem should be relative to the input
source I provided. Like this I can move the sources and the image around as I please.
Of course. This is what every reasonable parser does.
I thought so :)
Thanks for all the work. Please let us know if there are any new developments.
Cheers,
Doru
--
www.tudorgirba.com
"Live like you mean it."
thanks Doru for the detailed review.
I did some of the easy things.
I guess it should not be difficult.
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.
Exactly. This is the semantics of stub (everything I did not tell you to look at
explicitly).
You are the third one.
When we reach the total of 741 people asking for it, I will put it in
the wish list :-)
4 to: 741 do: [:i | nicolas pleaseUpdateTheMeaningOfStub ] :)
OK, I will think about it, actually it should not be too difficult
Yes. The best thing would be to create a FAMIX.Interface which should be a subclass of
FAMIX.Type. This does not exist yet, but I will add one in the Pharo FAMIX.
(-) 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)