12 Apr
2013
12 Apr
'13
1:32 p.m.
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)