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
Hi,
In Java, we do not create FAMIXPackages (yet). We only create FAMIX Namespace because it is enough for most practical purposes.
As you noted, Package and Namespace model two distinct relationships and I do not see how they can get unified (this was an intense debate some 5-7 years ago).
I think that modeling children solely on belongsTo can be a reasonable default implementation, but the subclasses should be allowed to customize this. This will solve the problem in Package.
Cheers, Doru
On Tue, Jul 21, 2015 at 2:42 PM, Anne Etien anne.etien@univ-lille1.fr wrote:
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:
- 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 _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Anne Etien -
Tudor Girba