27 Aug
2010
27 Aug
'10
12:05 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev