19 Aug
2010
19 Aug
'10
9:37 a.m.
2010/8/18 Simon Denier <Simon.Denier(a)inria.fr>
On 18 août 2010, at 17:07, Cyrille Delaunay wrote:
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'
So now it''s the same
as CandidateListOperatorAcceptingSimpleKindsOfReceiver right?
yes
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.
CandidateListOperatorAcceptingBasicAndVariableReceivers
CandidateListOperatorAcceptingSimpleKindsOfReceiver
are nowadays the same?
yes
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)
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:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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