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.

2010/8/18 Simon Denier <Simon.Denier@inria.fr>

On 18 août 2010, at 16:27, Alexandre Bergel wrote:

> I will try. In the meantime, I created a new issue.
> http://code.google.com/p/moose-technology/issues/detail?id=435

Maybe it would be better to open an issue about testing AbstractCandidateListOperator subclasses, since they already use RoelTyper.

Cyrille, could you make a quick summary of the strategies available?

>
> Cheers,
> Alexandre
>
>
> On 18 Aug 2010, at 09:42, Simon Denier wrote:
>
>> 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!
>>
>>
>>
>> On 18 août 2010, at 15:21, Alexandre Bergel wrote:
>>
>>> 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.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev@iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev@iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev