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
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.
On Tue, Jul 21, 2015 at 2:42 PM, Anne Etien <anne.etien(a)univ-lille1.fr>
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?
Moose-dev mailing list
"Every thing has its own flow"