On 27 août 2010, at 12:05, Stéphane Ducasse wrote:

On Aug 26, 2010, at 6:55 PM, Simon Denier wrote:

...

I am reviewing the code relating to invocations in Famix. I noticed the following.

FamixInvocation>>to ^ self receiver

Receiver can be a variable or a class, but can also be nil. This seemed a reasonable default at one time, because we do not necessarily now which method we are invoking (but again, we may not have a clear receiver to refer too).

indeed an invocation is a message send. and sometimes we know the method but we may also not

So it is for receiver: sometimes we know (self, ClassX, local variable...), sometimes we don't (chained calls)

...

However, with respect to other associations, consider:

...

FamixReference: from -> aMethod to -> aClass

how should I read it?

Verbatim (almost): a FamixReference is from a Method to a Class

...

FamixInheritance: form -> aClass to -> aClass FamixAccess: from -> aMethod to -> aVariable FamixInvocation: from -> aMethod to -> aVariable or a Class ??? (FamixExtension: from -> aPackage to -> aClass (well, this one is just future work :) )

It seems much more intuitive to have: FamixInvocation: from -> aMethod to -> aMethod

indeed this is really the question of what is to compare to receiver. I think that if you do not deprecate receiver then this sounds good

Yes we don't deprecate receiver.

...

Now of course, how do we refine that when we may have multiple candidates?

What would be a reasonable default?

FamixInvocation>>to ^ self candidates ifNotEmpty: [ self candidates any ]

now why to in such a case is not to methodS because taking one arbitrary looks to me like the worse we can do

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.

...

or: FamixInvocation>>to ^ self candidates

Actually, this one has my preference even if slightly different, because with the other choices we make hypothesis which are not clear.

FamixInvocation: from -> aMethod to -> a collection of Methods (candidates)

Yes!

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