20 Nov
2012
20 Nov
'12
5:52 p.m.
so explaining because Damien Cassou also told me he did not get it all.
First the idea of static typing just came because when we discuss our
problems it is just like we were discussing problems of java programming:
for example: "yes this entity has the right property, but this
association cannot link to it, so maybe we should define a new super
entity of both ..."
And the problems are htat if I represents more specific elements of a
new language, I want the tools to use and manipulate this information.
Let me try an example:
I want all the methods in a package/namespace
- a basic definition is all methods of all classes in the
package/namespac. This should work for C# by example.
- then if I consider ST, I should includ extensions
- then if I consider java, I should also consider all interfaces (they
are represented as classes, easy), methods defined in classes defined in
classes defined in the package (inner classes), methods defined in
classes defined in methods defined ... (anonymous classes)
An then it becomes difficult to have a generic tool.
multiply this by all little small differences that can happen in all
entities (friend classes in C++, partial classes in C#, struct in Java,
static import of method in Java, ...) and you can get a nice mess if you
want to be able to treat many languages.
nicolas
On 20/11/12 14:51, Fabrizio Perin wrote:
Hi Nicolas,
sorry but I did understand what you said. If I need more specific
elements in the model to represent more specific elements of my
reality that doesn't make the tool less generic.
I personally added to the moose model elements that with languages
have little to do like, for example, a model for conceptual schemas or
a model for relational database structures and everything is still
generic as before. If I don't need to analyze relational databases I
can always avoid even to load that extension. I agree that if you need
to analyze something new the work load could be high but the whole
idea behind moose is exactly to make that workload less than the one
you have by starting from scratch.
About a different way to deal with model extensions I'm also
interested in discuss further about it. What I think could be improved
is the way Moose is loaded: you should be able to cherry pick the
extensions you need and forget about the rest.
About the specific problem you mentioned, I wasn't aware of it (also
because it causes no problems with my code/analyses), so I cannot
answer and I would like to learn more about it.
Cheers,
Fabrizio
2012/11/20 Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr>fr>:
We have been discussing here for long time that
the meta-model approach of
Moose is not that much adapted to the problems of reverse engineering.
Because we need to model detailed informations on the programs being
modeled, Famix has many entities that are language specific.
Up to now we manage because Moose "core" deals with only two languages: Java
and Smalltalk
But if we wanted to deal with other languages C#, PHP, Python, Java-script,
Cobol, Pascal, Lisp, ... we would have to add entities and/or constructs
specific to each language and the tools would become less and less generic.
More recently, it occurred to me that this is very similar to the kind of
issues one has to deal with in a statically typed language (Java is evil :-)
).
So basically Famix introduced static typing in Moose.
If this analysis is correct, the questions would be:
- was it necessary to go that way? why?
- is there another way to do it? more in tune with the smalltalk way of
life?
nicolas
_______________________________________________
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