Using RoelTyper for a better precision of method invocation

[seandenigris]

Originally reported on Google Code with ID 435

Email sent on Aug 18, 2010:

Hi!

I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong dependencies
are inferred whereas I am sure that they do not exist. This is not a new, we have to
type in Smalltalk. For example:

MOEdge>>fromPositions
    ^ shape fromPositions

#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.

In the case of MOEdge>>fromPositions, I am sure that it does not invoke MOAbstractLayout>>fromPositions

I guess that everyone analyzing smalltalk code bumped into this very situation. 

My question is how do we do in that case? 
One easy solution, is to annotate Mondrian with an adequate pragma:

MOEdge>>fromPositions
    <invoke: #fromPositions of: MOLineShape>
    ^ shape fromPositions

We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>

Simon told me Cyrille has worked on this problem. I am currently trying to use RoelTyper.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Hi Alex

Did you try the different strategies provided for invocations resolution in the importer
wizard? Indeed, Cyrille coded a few strategies to use RoelTyper for better method resolution
(as well as inference of instance variable types). Unfortunately, there are no test
for this so I don't no how reliable it is. I would love to have tests and precision/recall
score for these strategies!

Reported by alexandre.bergel on 2010-08-18 14:26:33

[seandenigris]

From Cyrille

So strategies available are:

a CandidateListOperator (the class used at the origin, could maybe be removed) compute
a list of possible type for a FamixInvocation's receiver when:

- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'

a CandidateListOperatorAcceptingAnyKindOfReceiver compute a list of possible type for
a FamixInvocation's receiver when:

- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
should normally accept any kind of receiver, but all type are not yet supported or
implemented.

a CandidateListOperatorAcceptingBasicAndVariableReceivers  compute a list of possible
type for a FamixInvocation's receiver when:

- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute

a CandidateListOperatorAcceptingSimpleKindsOfReceiver compute a list of possible type
for a FamixInvocation's receiver when:

- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'  (so does the same job than the original class)


a CandidateListOperatorNotAcceptingAnyReceiver doesn't compute any possible type.

should normally accept any kind of receiver, but all type are not yet supported or
implemented.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From Simon:

Nowadays there are some tests for candidates, which imply testing CandidateListOperator.
We should have independent tests for each strategy (best would be to extract the current
tests for candidates, and also start testing CandidateListOperatorAcceptingBasicAndVariableReceivers
which might have good precision)

Reported by alexandre.bergel on 2010-08-18 15:30:17

[seandenigris]

See http://code.google.com/p/moose-technology/issues/detail?id=252 for original issue

Reported by simon.denier on 2010-08-18 15:47:15

[seandenigris]

Reported by simon.denier on 2010-08-23 11:24:31

• Labels added: Type-Enhancement
• Labels removed: Type-Defect

[seandenigris]

It seems that RoelTyper does not work for all classes. Try this code for getting the
classes that raise an error:

classes := Dictionary new.
Object withAllSubclassesDo: [:each |
       [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes
at: each put: error ]].
classes inspect

Reported by tudor.girba on 2011-04-26 20:50:38

• Labels added: Component-SmalltalkImporter

[seandenigris]

In Moose 4.7, it seems that only ColoredDSM is affected by this. It would be great if
someone would take a look at this.

Reported by tudor.girba on 2012-03-20 06:51:19

[seandenigris]

Ok, I will take a look.

Reported by jannik.laval on 2012-03-21 06:34:50

[seandenigris]

I do not understand what is the problem.

Reported by jannik.laval on 2012-03-22 10:49:08

[seandenigris]

This is likely not a DSM problem, but a RoelTyper one :). It's just that it exhibits
in the ColoredDSM class.

To reproduce just run this code in the latest Moose image.

classes := Dictionary new.
Object withAllSubclassesDo: [:each |
       [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes
at: each put: error ]].
classes inspect

You will get a list of all the classes for which RoelTyper throws an error. There used
to be several of these, but somehow now we get only one.

Reported by tudor.girba on 2012-03-22 10:54:53

[seandenigris]

This seems to not be a problem in Pharo 3.0 anymore.

Reported by tudor@tudorgirba.com on 2013-11-11 05:26:37

• Status changed: Fixed
• Labels added: Milestone-5.0