Users of TDependencyQueries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Users of TDependencyQueries

CyrilFerlicot
Le 06/11/2017 à 19:00, Anne Etien a écrit :

>
>> Le 6 nov. 2017 à 18:40, Cyril Ferlicot D. <[hidden email]> a écrit :
>>
>> Le 06/11/2017 à 18:36, Anne Etien a écrit :
>>>
>>> I don’t remember why. Perhaps it is a design error.
>>> I would have to make some test to have be sure. But no time to do it in
>>> the next two weeks at least or even more. Sorry.
>>> If you want, try to remove TMetaLevelDependencies in the traits used by
>>> TAssociationMetaLevelDependency.
>>>
>>
>> Those are not only in TAssociationMetaLevelDependency but also in
>> TMetaLevelDependencies used by FAMIXEntity.
>
> Not understood the answer.
If we remove TMetaLevelDependencies from
TAssociationMetaLevelDependency, associations will still have
#children/#parents/#atScope:/#toScope:…

Or maybe I did not understood you last sentence on the previous mail.

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


--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Users of TDependencyQueries

Nicolas Anquetil
In reply to this post by CyrilFerlicot


On 06/11/2017 18:24, Cyril Ferlicot D. wrote:

> Le 06/11/2017 à 18:02, Tudor Girba a écrit :
>> 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?
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

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