On 04/11/2013 09:04 AM, stephane ducasse wrote:
Nicolas

I would really like if you could (with camille/anne/damien/usman) have a document (can a couple of slide)
where you precisely shows the problem synectiquers encountered with FAMIX. 
It will help for the solution/paper :)
And it will help me to understand what are the key problems.

Stef

Some problems we see with current Famix.
Several of them just say that entities have too many properties that do not make sense for them.
Other could be solved by adding more properties to generic entities.
This is what prompted us to think about multiple inheritance (or traits :-) ) to compose new entities from a set of simple "properties" (not in Famix sense of property).

- Invocation is designed for OO. There is no receiver in procedural languages. This is a semantical problem, but practical too as 'printOn:' has to be redefined to show 'from -> to' instead of 'from -> receiver'

- Invocation is designed for "non-typed language". In statically typed languages or procedural languages one knows (or has a pretty good idea) the function/method called. In these cases, 'candidates' adds unnecessary complexity

- Some relations between entities are reified (Associations) other not. E.g. Access is an association, but the type of a variable is a "simple" relation. BelongsTo is not reified, neither is AnnotationInstances, ...

- Abstract Famix classes like NamedEntity inlude many properties that are Java specific (isAbstract, isFinal, isPublic, ...), so that a Function, a Package or a LocalVariable have the isAbstract, isFinal properties and AnnotationInstances relation.

- This is further complicated by the fact that these properties are derived from 'modifiers'. So when looking at the meta-description of NamedEntites, one sees many redundant properties.

- A language like Cobol has no functions, it has paragraph that is a sequence of statement with a label to go to it and a return statement (with no value) at the end. For them 'signature' and 'parameters' are meaningless.

- 'functions' are defined for ScopingEntity which is not a BehaviouralEntity. But there are cases where we want both (a Pascal program would be an example)

- all sourcedEntities have a sourceAnchor and comments, which does not make sense for ScopingEntities, or ImplicitVariables

- for synectique we want an alternative notion of container where a container only contains BehaviouralEntity, not other entities (a Smalltalk method would not be a container).

nicolas

-- 
Nicolas Anquetil -- RMod research team (Inria)