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
However, with respect to other associations, consider:
FamixReference: from -> aMethod to -> aClass
how should I read it?
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
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
FamixInvocation>>to ^ self isASureInvocation ifTrue: [ self candidates first ] (sure invocation does not imply one candidate, so it may still break or be inconsistent)
FamixInvocation>>to ^ self candidates size = 1 ifTrue: [ self candidates first ]
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!
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev