Hey Doru,
I did not manage to achieve this, can you take care?
We want to have
- sendToBack
- bringToFront
- sendBackword
- bringForward
in the context menu of Mondrian figure.
(as in Excel par example)
cheers,
AA
Hi guys
we have been discussing with alex here about our visibility since
other groups at inria are using Gforge and are counting their
donwloads. I think that we cannot do too much because I do not see
how it would make sense to use svn for developing Moose.
Now I see several paths to help moose while helping us (stef at
inria) internally:
I think tat this is really important to refer to the moose articles
in the paper and PhD thesis.
Oscar Nierstrasz, Stéphane Ducasse and Tudor Gîrba, The Story of
Moose: an Agile Reengineering Environment, In Proceedings of the
European Software Engineering Conference (ESEC/FSE 2005), New York
NY, ACM Press, pp. 1-10, 2005, Invited paper, PDF , DOI
Stéphane Ducasse, Tudor Gîrba, Michele Lanza and Serge Demeyer,
Moose: a Collaborative and Extensible Reengineering Environment, In
Tools for Software Maintenance and Reengineering, Milano, Franco
Angeli, pp. 55-71, 2005, PDF
Stef
Hi,
In the latest version 1.313, DynaMoose seems to have lost its tests.
Is this by mistake, or is it intended?
Cheers,
Doru
--
www.iam.unibe.ch/~girbawww.iam.unibe.ch/~girba/blog/
"The coherence of a trip is given by the clearness of the goal."
There was discussion if it might be possible to omit the list of
invocation candidates and just give the "most common candidate" and
derive all others.
Please find below an example where this does not work for statically
types languages.
The client class invokes m() on an instance of B. m is implement in
A (B's superclass) and C and D (B's subclasses), but also in E (a
sibling of B). Lets assume we just store the "most common candidate"
A.m and derive candidates looking at subclasses, then we get the
false positive E.m!
Another case (which applies to dynamic languages too) is when m() is
invoked using a super send somewhere in D, and we just store A.m()
and we derive it now, again D.m and E.m and C.m are false positive.
So at least you need information about
receiver type
signature (not yet 1st class in FAMIX!)
kind of lookup (self, super, whatever...)
whereas the "most specific candidate" encodes implementing type and
signature as string.
So for now, maybe best is to just store all candidates in any case.
cheers,
Toon and AA
