Famix = static typing
Locked
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]>: > 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]>: >> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Nicolas,
Thanks for opening the discussion, and sorry for the late reply but I was a bit ill the last days. I think the discussion is valid, but you are mixing two distinct concerns: the deep FAMIX inheritance model, and the traversals.
1. Inheritance-based modelling This has indeed some historical roots and some constraints: - We designed it in VW before Traits were usable - We used the types capabilities in Fame to be able to generate code in multiple languages
We wanted since a long time to extend it to use Traits, but nobody got time to lo it. However, in the meantime, Alain Plantec did extend the Pharo version of Fame to use Traits. We need to integrate this into Fame, and then ideally take care that the same implementation happens in Java as well, so that VerveineJ can benefit from the code generation.
Using Fame Traits, we can nicely have the type of a property point to the Trait, rather than the MetaDescription. Nevertheless, I think this is less of a problem in practice because you can easily extend your meta-model with new properties. What you cannot do, is change the meaning of one property, but that you will not be able to do with Traits either. However, what you could gain with Traits would be to compose a new entity faster. That would definitely be cool.
2. Traversals In your example, allMethods is essentially a travesal of the system. First, this is one traversal of the system, and if you have another semantics, you should create another one. But, ideally, traversal engines should be separate from the model (Karl Lieberherr (http://www.ccs.neu.edu/home/lieber/) is a prominent advocate of this). For example, to some extent this is what happened with Chef: it offered operators that could be composable and that reside outside of the model. For another example, the FAMIXGraphVisitor I created lets you crawl through FAMIX by defining a traversal that is independent of the model. It would definitely be great to have more of these.
However, fancy traversals also come with a cognitive cost, and we should always strive to strike a balance between what is generic and what is practical. But, another thing to keep in mind is that the new focus of Moose is less on FAMIX as a generic meta-model, but on building dedicated new ones faster. We no longer are driven by large costs of the tools built on top of the meta-model, because we constantly decrease those costs with engines like Glamour or Roassal.
In summary, having: - Traits in Fame and FAMIX would be interesting for enabling the composition of a new entity out of smaller pieces - Building new kinds of traversals and aggregators (like Carrack) would be equally interesting for quickly putting together queries that need to deal with the newly created semantics
Cheers, Doru
On Tue, Nov 20, 2012 at 5:52 PM, Nicolas Anquetil <[hidden email]> wrote:
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |