29 Jul
2011
29 Jul
'11
1:48 p.m.
On 29 juil. 2011, at 11:38, Tudor Girba wrote:
Hi Simon,
Indeed, I also looked into the possibility of having a
MooseObjectQueryResult>>withoutSelfLoops. It would be cool to have it like that, but
it does not seem possible currently because we do not have enough context.
I only have the receiver, and I do not know what kind of scoping was used. I guess that
with scoping information, it would be enough, right?
The basic scope is the one of the receiver, which you can obtain with #yourScope.
Then when sending an #atSomethingScope message, my guess is that the
MooseObjectQueryResult should also save the scope so that it is available for example in
#withoutSelfLoops
Any ideas?
Cheers,
Doru
On 29 Jul 2011, at 11:26, Simon Denier wrote:
--
Simon Denier
On 28 juil. 2011, at 23:10, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I want to reimplement software engineering
metrics using moose chef instead of moose cook.
for example to compute cohesion I would do (among other things):
self queryAllOutgoingDependencies atClassScope withinMyPackage
i.e. :
1- from a package (self)
2- get all its "outgoingdependencies" (outgoing does not mean going outside the
package, this includes dependencies within th package)
3- put that at class level (because we are interested in dependencies between classes
within or outside the package)
4- and filter those that are inside self
OK, I see what you mean. When I refactored Cook into MooseChef, there was lots of small
decisions about the "best" default choice i.e., the least surprising choice.
Unfortunately I also realized that such choices do not work in all cases. The underlying
principle is that default choices in MooseChef works best bottom-up: that is, starting
from the low-level entities (methods, classes) up to enclosing entities (classes,
packages). Conversely, you have to be careful when working top-down and that's because
of the self loops exclusion.
So my proposed solution for this is to work "bottom-up": instead of collecting
dependencies directly at package level, you start to work at class level.
aPackage classes collect: [ :class | class queryAllOutgoingDependencies atClassScope
withinMyPackage ]
But again, this might or might not be the expected result because you exclude self loops
at class scope then (i.e. no ClassA -> ClassA relation, this might or might not be what
you want). If this is not what you want, you might go to the level of methods, and then
again self loops are exclude but at method level (i.e. recursive calls are excluded).
I really don't know what's the best:
- keep the current semantic which plays nicely bottom-up (however, the above case shows
it's not really consistent with "least surprise" :) )
- or be less intelligent and let the user chooses himself whether or not he wants self
loops as proposed by Doru. This way MooseChef would be more adaptable to any case.
I am not very happy with the proposed API enhancements but it can be a temporary
solution. I would rather make #withoutSelfLoops works with MooseObjectQueryResult
(currently, #withoutSelfLoops works only with primitive queries). Then I could write (for
example):
aPackage queryAllOutgoingDependencies atClassScope withoutSelfLoops
I want the result to be all dependencies from classes within package self going to
classes within package self.
but (from the moose chef documentation):
"The scope operators exclude self loops by default (this was also the default in
Moose Cook). That is, the query result will not contain the receiver scope itself: you
will not get something like PackageX -> PackageX in the result (the reason for this is
that in general algorithms do not like graphs with self loops)."
So:
- should we change that default?
- should I change my query?
I believe if there is a method to exclude self loops (withoutSelfLoop), it should not be
done automatically in some case let those who want it do it themselves.
What say you?
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev