18 Aug
2010
18 Aug
'10
5:07 p.m.
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(a)inria.fr>
On 18 août 2010, at 16:27, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev