Smalltalk › Frameworks & Tools › Moose

semantics of famix reference

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Usman Bhatti

semantics of famix reference

Hi,

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 question:

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?

regards.

Usman

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Nicolas Anquetil

Re: semantics of famix reference

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)

nicolas

On 08/07/2016 11:38, Usman Bhatti wrote:

Hi,

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 question:

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?

regards.

Usman
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

-- 
Nicolas Anquetil
RMod team -- Inria Lille

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev