13 Apr
2013
13 Apr
'13
9:08 a.m.
On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote:
On 04/11/2013 09:04 AM, stephane ducasse wrote:
give example
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.
but usless for others :).
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).
traits-based :)
indeed traits should be good for that.
Probably what you want is to have pair of traits that you apply to both end of a relation
also.
- 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'
but we could have a superclass for call and a subclass for invocation?
- 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
Really? In Java there are cases where you do not know. For example if you have an
interface: you may have different classes?
- 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.
this is the question of what is your domain and if you
have to attach information to the relation.
To me I do not see why I would like a relation for type.
BelongsTo is not reified,
Why do you want to
have pointers as relations?
To me it will blow up metamodels for not. I do not see the value of having a method
belongs to a class as a relation.
neither is AnnotationInstances, …
there it could make sense.
- 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.
Yes the tyranny of the dominant decomposition but now do you want to have to express
everywhere where
- 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.
yes probably should be rethought
- 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.
so you will have a hard job to always compose a new model for each language if you do not
accept some interpretation.
It also means that you will have hard time to reuse tools.
- '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)
this is a nice one :)
- 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).
so it would be interesting to start identifying the traits you want to have a build a
libraries.
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev