Hi,
I am working on a new generic version of MooseChef. The idea is that from an element, we
can reach its children by looking at the entities whose opposite of the « belongsTo »
property is this element. The idea is not to take into account the specificities of the
FAMIX context as it is done currently, but to use an API that is not aware of the FAMIX
concept on which it is applied and thus that is the same for any FAMIX concept already
existing or not yet.
Currently, we got different issues:
1. in Smalltalk, classes are in the childnamedEntities collection of a FAMIXPackage
whereas they are in the types of a FAMIXNamespace in Java. The problem is that FAMIXClass
has not its own belongsTo method, but inherits it from FAMIXType. So the opposite of the
belongsTo method for a FAMIXClass is types and not childnamedEntities.
2. in Smalltalk, extension methods are also in the childnamedEntities collection of a
FAMIXPackage. However, if you invoke the belongsTo method from an extension method, you
get the class and not the package. Moreover, in the current version of MooseChef,
associations from and to an extended method are taken into account both when querying the
class and the package. In a kind of way, an extended method belongs to both the class and
the package. However, it is not possible at the model level to say that an element belongs
to two elements.
We can fix the first issue by modifying the SmalltalkImporter and the FAMIX model in order
that classes are collected in the types collection as in the case of Java. Consequences on
the new version of MooseChef are the following: we can reach the classes from the package
what is not possible currently and the association from and to the extension methods are
considered only when querying the class belonging these extension methods, but not the
package.
What do you think about this change?
Anne