Smalltalk › Frameworks & Tools › Moose

Ramblings about FamixInvocation#to, #receiver, #candidates

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Simon Denier-3

Ramblings about FamixInvocation#to, #receiver, #candidates

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).

However, with respect to other associations, consider:
FamixReference: from -> aMethod to -> aClass
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

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 ]

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)

--
Simon

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: Ramblings about FamixInvocation#to, #receiver, #candidates

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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Simon Denier-3

Re: Ramblings about FamixInvocation#to, #receiver, #candidates

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev