18 Aug
2010
18 Aug
'10
8:25 p.m.
On 18 août 2010, at 17:31, Alexandre Bergel wrote:
Yeah, this is what I thought.
Maybe we could introduce CandidateListTypeInferencer that use Roel Typer?
Once again, Roel Typer is already used in
CandidateListOperatorAcceptingBasicAndVariableReceivers and
CandidateListOperatorAcceptingAnyKindOfReceiver
to compute possible types for attributes.
See #computeInstanceVariableCandidateListFor:
Now there is still work to do
I entered what you said on
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe something can be added to the Moose Book.
Cheers,
Alexandre
On 18 Aug 2010, at 11:07, Cyrille Delaunay wrote:
--
Simon
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 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:
--
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 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