On 27 août 2010, at 12:05, Stéphane Ducasse wrote: So it is for receiver: sometimes we know (self, ClassX, local variable...), sometimes we don't (chained calls) Verbatim (almost): a FamixReference is from a Method to a Class Yes we don't deprecate receiver. That depends, if by any we mean first and if candidates came as sorted list of best candidates to worst candidates. But I don't think we should go in this direction. That's probably that we will do, even if it breaks a bit the nice regularity of #from/#to in FamixAssociation. The point of from/to is that you can write nice generic queries about associations. You want classes which are referenced by a method? aMethod outgoingReferences collect: [ :r | r to ] You want super classes/interfaces? aClass superInheritances collect: [ :i | i to ] You want variables accessed from a method? aMethod accesses collect: [ :a | a to ] Same for incoming dependencies: aClass incomingReferences collect: [ :r | r from ] --> Methods referring to class aClass subInheritances collect: [ :i | i from ] --> subclasses aVariable incomingAccesses collect: [ :a | a from ] --> Methods accessing the variable aMethod incomingInvocations collect: [ :i | a from ] --> Methods invoking the method Notice the nice regulariry, and that's something we want to use with Jannik to build reusable generic queries in a trait. That's the goal of MooseChef. But... aMethod outgoingInvocations collect: [ :i | a to ] --> a collection of collections of Methods invoked by the method So we have to flatten the collection at one point. Anyway, we will find a workaround... So you know a bit more about ongoing work :) -- Simon