18 Aug
2010
18 Aug
'10
5:31 p.m.
Yeah, this is what I thought.
Maybe we could introduce CandidateListTypeInferencer that use Roel Typer?
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:
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 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