27 Aug
2010
27 Aug
'10
2:01 p.m.
On 27 août 2010, at 12:05, Stéphane Ducasse wrote:
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
On Aug 26, 2010, at 6:55 PM, Simon Denier wrote:
So it is for receiver: sometimes we know (self, ClassX, local variable...), sometimes we
don't (chained calls)
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
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!