11 Nov
2017
11 Nov
'17
11:20 a.m.
On 06/11/2017 18:24, Cyril Ferlicot D. wrote:
Le 06/11/2017 à 18:02, Tudor Girba a écrit :
this is
wrong.
The problem actually comes from the fact that these methods are defined
at the FamixEntity level which is way to high in the inheritance hierarchy.
It does not make sense to ask the children of a sourceAnchor, nor its scope.
Same for FAMIXSourceLanguage
The problem is well known, we need some kind of "multiple-inheritance"
and hopefully, the Famix will provide it.
2 solutions:
- the best is the solution proposed by Anne, but it is a bot more work
- yours is a possible one if we believe the new Famix is coming real
soon and will be integrated in Moose immediately after
Reason tells me that we should not count for integration of newFamix in
Moose before sometime next year (maybe around pharo7.0 release ?)
So it would still be best to go with Anne's solution because history is
full of this-is-only-for-short-period-of-time solutions that lasted forever
(it is actually possible that the problems with children/... being too
high in the inheritance hierarchy stems from one of these decisions)
only my 2c
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
Hi,
The point of Traits is exactly to not require inheritance.
Why is it not good solution to add TEntityMetaLevelDependency to all classes that require
it regardless of the place in inheritance?
My problem is that: I know that a children selector will return a
FAMIXSourcedEntity and I need to send some messages to
FAMIXSourcedEntity that are in the Trait. But FAMIXSourcedEntity cannot
use the Trait if we do not accept that the associations will also get
the Trait.
If we introduce this FAMIXNonAssociationEntity then we will move
#comments and #containerFiles to this entity? Also FAMIXFile>>entities
should point to FAMIXNonAssociationEntity?
But once again… Why an association car understand
#atScope:/#children/#parents (which are queries) and not #queryAllIncoming?