I would go against a generic association that represents everything one
wants to put in it.
All the purpose of Famix (which is statically typed contrary to
Smalltalk) is to have semantics on the entities/links so one can reason
and/or make assumptions from the presence of a given entity/association
What would be the gain of having a link ready for anything?
Avoiding to define a new association when one has a specific need?
But this takes about 15min., not much of a gain
Finally, a generic link can as well be achive using FamixAssociation
(the superclass of reference/incovation/access/inheritance)
On 08/07/2016 11:38, Usman Bhatti wrote:
While loading one of my existing models, I remarked that the semantics
of FAMIXReference have been changed: earlier it was an association
between two containers and hence much more permissive. Now it is an
association between a method (from side) and a type (to side).
Although I agree that the semantics are clearer, sometimes we have the
need to represent an association/dependency between two entities. It
happens because we are reading from a abstracted source of information
(e.g. a description of the model from a modelling tool) that does not
have the code-level details.
So it will be good to have a more generic dependency. Hence, the
1. Does it make sense to add a generic dependency (between two
containers? sourced entities?)?
2. Should it be named FAMIXDependency as the word dependency can have
different meanings to different people (all dependencies of an entity
may be its "computed" dependencies from the dependencies of its
children or aggregate of all types of dependencies e.g. accesses,
invocations, etc.). So, we need to be careful about the naming.
With moose-chef, I would have to tell which entities have this
dependency for correct computation of the dependencies but with
MooseQuery, we should not have this problem because this information
is inferred from the meta-model, right?
Moose-dev mailing list
RMod team -- Inria Lille