28 Jul
2011
28 Jul
'11
11:10 p.m.
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
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
29 Jul
29 Jul
12:12 a.m.
Indeed, this situation could be improved, but I think the solution is different than what
you propose.
Currently, the exclusion of self loops happens at two levels:
1. withoutSelfLoops is result specific and it excludes the relationships based on the
input. So, something like
"aClass queryAllOutgoingDependencies withoutSelfLoops" will return all
dependencies that do not end in aClass
2. MooseQueryResult>>collectAtScope: rejects the results based on the scope
"aClass queryAllOutgoingDependencies atNamespaceScope" will return all target
namespaces involved in a dependency but that are not the namespace of the current class.
If you want to get the namespaces including the current one, you can play with the private
method "primCollectAtScope:":
"aClass queryOutgoingReferences primCollectAtScope: #namespaceScope"
All in all, the two ways of trimming are at different levels of abstraction.
So, I propose introducing methods like "atNamespaceScopeWithSelfLoops" or
"atNamespaceScopeWithoutSelfLoops". It is not so nice, but I do not see a clean
other solution.
I would probably prefer to have atNamespaceScope to return all namespaces, including self
loops, and introduce "atNamespaceScopeWithoutSelfLoops". What do you say?
Cheers,
Doru
On 28 Jul 2011, at 23:10, Nicolas Anquetil wrote:
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
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
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
11:26 a.m.
On 28 juil. 2011, at 23:10, Nicolas Anquetil wrote:
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
11:38 a.m.
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?
Any ideas?
Cheers,
Doru
On 29 Jul 2011, at 11:26, Simon Denier wrote:
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."
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
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
1:54 p.m.
Hi,
On 29 Jul 2011, at 13:48, Simon Denier wrote:
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
On 29 juil. 2011, at 11:38, Tudor Girba wrote:
Right, this is was my idea as well :).
Cheers,
Doru
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
8 Aug
8 Aug
10:35 p.m.
Hi,
I just pushed a change removing the selfloop exclusion in scoping methods.
Ignoring the 60+ tests that needed to be updated, most of the work consisted in finding
the right definition for FamixMooseOutgoingCompositeQueryResult>>collectAtScope:
But this did not involve playing with the 'receiver' instance variable as
mentioned in the emails.
All (updated) tests are green
The initial behaviour should be available by calling explicitly 'withoutSelfLoops'
on the result of a at___Scope (although I realize I did not test that explicitly).
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 29 Juillet 2011 13:54:02
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self loops
Hi,
On 29 Jul 2011, at 13:48, Simon Denier wrote:
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 29 juil. 2011, at 11:38, Tudor Girba wrote:
Right, this is was my idea as well :).
Cheers,
Doru
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 28 juil. 2011, at 23:10, Nicolas Anquetil wrote:
> 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
--
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
9 Aug
9 Aug
12:27 p.m.
Hi Nicolas,
Thanks for looking into this.
I have a couple of issues.
1. you did not commit the tests :)
2. I read the code, but I fail to see how you can get the semantics we discussed below by
calling withoutSelfLoops. Could you maybe explain and provide an example?
3. I do not understand why you removed primCollectAtScope:. It was a clean way to separate
the creation of the new result from the actual query. For example, now you get:
MooseQueryResult subclass: #MooseIncomingQueryResult
uses: TDependencyQueryResult - {#primCollectAtScope:}
I would prefer to keep the previous separation. In fact, it seems to me that we can obtain
the same results as you have now by simply commenting the reject statement from:
MooseQueryResult>>collectAtScope: aScopeSymbol
| sourceScope |
sourceScope := receiver perform: aScopeSymbol.
^ self newObjectResultWith:
((self primCollectAtScope: aScopeSymbol)
"reject: [ :scope | sourceScope mooseIncludes: scope
]") "exclude self loops"
This is a tricky change and we should look into it closely. My solution would be to:
- remove the default reject (see above)
- add the receiver to MooseObjectQueryResult
- implement MooseObjectQueryResult>>withoutSelfLoops to use it
I do not have time right now, but it would be great if you or someone else could spend
time on this.
Cheers,
Doru
On 8 Aug 2011, at 22:35, Nicolas Anquetil wrote:
Hi,
I just pushed a change removing the selfloop exclusion in scoping methods.
Ignoring the 60+ tests that needed to be updated, most of the work consisted in finding
the right definition for FamixMooseOutgoingCompositeQueryResult>>collectAtScope:
But this did not involve playing with the 'receiver' instance variable as
mentioned in the emails.
All (updated) tests are green
The initial behaviour should be available by calling explicitly
'withoutSelfLoops' on the result of a at___Scope (although I realize I did not
test that explicitly).
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 29 Juillet 2011 13:54:02
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self loops
Hi,
On 29 Jul 2011, at 13:48, Simon Denier wrote:
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
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
On 29 juil. 2011, at 11:38, Tudor Girba wrote:
Right, this is was my idea as well :).
Cheers,
Doru
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:
>
> On 28 juil. 2011, at 23:10, Nicolas Anquetil wrote:
>
>> 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
--
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
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:48 p.m.
Hi,
I will look into this.
But not this week as I am working on a project.
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 9 Août 2011 12:27:00
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self loops
Hi Nicolas,
Thanks for looking into this.
I have a couple of issues.
1. you did not commit the tests :)
2. I read the code, but I fail to see how you can get the semantics we
discussed below by calling withoutSelfLoops. Could you maybe explain
and provide an example?
3. I do not understand why you removed primCollectAtScope:. It was a
clean way to separate the creation of the new result from the actual
query. For example, now you get:
MooseQueryResult subclass: #MooseIncomingQueryResult
uses: TDependencyQueryResult - {#primCollectAtScope:}
I would prefer to keep the previous separation. In fact, it seems to
me that we can obtain the same results as you have now by simply
commenting the reject statement from:
MooseQueryResult>>collectAtScope: aScopeSymbol
| sourceScope |
sourceScope := receiver perform: aScopeSymbol.
^ self newObjectResultWith:
((self primCollectAtScope: aScopeSymbol)
"reject: [ :scope | sourceScope mooseIncludes: scope ]") "exclude self
loops"
This is a tricky change and we should look into it closely. My
solution would be to:
- remove the default reject (see above)
- add the receiver to MooseObjectQueryResult
- implement MooseObjectQueryResult>>withoutSelfLoops to use it
I do not have time right now, but it would be great if you or someone
else could spend time on this.
Cheers,
Doru
On 8 Aug 2011, at 22:35, Nicolas Anquetil wrote:
Hi,
I just pushed a change removing the selfloop exclusion in scoping
methods.
Ignoring the 60+ tests that needed to be updated, most of the work
consisted in finding the right definition for
FamixMooseOutgoingCompositeQueryResult>>collectAtScope:
But this did not involve playing with the 'receiver' instance
variable as mentioned in the emails.
All (updated) tests are green
The initial behaviour should be available by calling explicitly
'withoutSelfLoops' on the result of a at___Scope (although I realize
I did not test that explicitly).
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 29 Juillet 2011 13:54:02
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self
loops
Hi,
On 29 Jul 2011, at 13:48, Simon Denier wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
Right, this is was my idea as well :).
Cheers,
Doru
>
> Any ideas?
>
> Cheers,
> Doru
>
>
>
> On 29 Jul 2011, at 11:26, Simon Denier wrote:
>
>>
>> On 28 juil. 2011, at 23:10, Nicolas Anquetil wrote:
>>
>>> 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
>
> --
> 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
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10 Aug
10 Aug
1:51 p.m.
I had half an hour free, so I wanted to commit the tests.
But I might have goofed up, the changes I now see are not those I did.
And now my time is up.
So, I will have to look at it again but this time with calm ...
sorry about this.
nicolas
----- Mail original -----
De: "Nicolas Anquetil"
<nicolas.anquetil(a)inria.fr>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 9 Août 2011 13:48:30
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self loops
Hi,
I will look into this.
But not this week as I am working on a project.
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 9 Août 2011 12:27:00
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self
loops
Hi Nicolas,
Thanks for looking into this.
I have a couple of issues.
1. you did not commit the tests :)
2. I read the code, but I fail to see how you can get the semantics
we
discussed below by calling withoutSelfLoops. Could you maybe explain
and provide an example?
3. I do not understand why you removed primCollectAtScope:. It was a
clean way to separate the creation of the new result from the actual
query. For example, now you get:
MooseQueryResult subclass: #MooseIncomingQueryResult
uses: TDependencyQueryResult - {#primCollectAtScope:}
I would prefer to keep the previous separation. In fact, it seems to
me that we can obtain the same results as you have now by simply
commenting the reject statement from:
MooseQueryResult>>collectAtScope: aScopeSymbol
| sourceScope |
sourceScope := receiver perform: aScopeSymbol.
^ self newObjectResultWith:
((self primCollectAtScope: aScopeSymbol)
"reject: [ :scope | sourceScope mooseIncludes: scope ]") "exclude
self
loops"
This is a tricky change and we should look into it closely. My
solution would be to:
- remove the default reject (see above)
- add the receiver to MooseObjectQueryResult
- implement MooseObjectQueryResult>>withoutSelfLoops to use it
I do not have time right now, but it would be great if you or
someone
else could spend time on this.
Cheers,
Doru
On 8 Aug 2011, at 22:35, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I just pushed a change removing the selfloop exclusion in scoping
methods.
Ignoring the 60+ tests that needed to be updated, most of the work
consisted in finding the right definition for
FamixMooseOutgoingCompositeQueryResult>>collectAtScope:
But this did not involve playing with the 'receiver' instance
variable as mentioned in the emails.
All (updated) tests are green
The initial behaviour should be available by calling explicitly
'withoutSelfLoops' on the result of a at___Scope (although I
realize
I did not test that explicitly).
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 29 Juillet 2011 13:54:02
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self
loops
Hi,
On 29 Jul 2011, at 13:48, Simon Denier wrote:
>
> 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
Right, this is was my idea as well :).
Cheers,
Doru
>
>
>>
>> Any ideas?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 29 Jul 2011, at 11:26, Simon Denier wrote:
>>
>>>
>>> On 28 juil. 2011, at 23:10, Nicolas Anquetil wrote:
>>>
>>>> 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
>>
>> --
>> 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
>
> --
> Simon Denier
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
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
2:46 p.m.
Hi Nicolas,
Because it broke the build (61 failures), and because the changes need review and have a
deep impact, I now moved the version into the MoosePlayground repository.
Everything is back to green now.
Cheers,
Doru
On 10 Aug 2011, at 13:51, Nicolas Anquetil wrote:
I had half an hour free, so I wanted to commit the
tests.
But I might have goofed up, the changes I now see are not those I did.
And now my time is up.
So, I will have to look at it again but this time with calm ...
sorry about this.
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Some battles are better lost than fought."
De: "Nicolas Anquetil"
<nicolas.anquetil(a)inria.fr>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 9 Août 2011 13:48:30
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self loops
Hi,
I will look into this.
But not this week as I am working on a project.
nicolas
----- Mail original -----
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 9 Août 2011 12:27:00
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self
loops
Hi Nicolas,
Thanks for looking into this.
I have a couple of issues.
1. you did not commit the tests :)
2. I read the code, but I fail to see how you can get the semantics
we
discussed below by calling withoutSelfLoops. Could you maybe explain
and provide an example?
3. I do not understand why you removed primCollectAtScope:. It was a
clean way to separate the creation of the new result from the actual
query. For example, now you get:
MooseQueryResult subclass: #MooseIncomingQueryResult
uses: TDependencyQueryResult - {#primCollectAtScope:}
I would prefer to keep the previous separation. In fact, it seems to
me that we can obtain the same results as you have now by simply
commenting the reject statement from:
MooseQueryResult>>collectAtScope: aScopeSymbol
| sourceScope |
sourceScope := receiver perform: aScopeSymbol.
^ self newObjectResultWith:
((self primCollectAtScope: aScopeSymbol)
"reject: [ :scope | sourceScope mooseIncludes: scope ]") "exclude
self
loops"
This is a tricky change and we should look into it closely. My
solution would be to:
- remove the default reject (see above)
- add the receiver to MooseObjectQueryResult
- implement MooseObjectQueryResult>>withoutSelfLoops to use it
I do not have time right now, but it would be great if you or
someone
else could spend time on this.
Cheers,
Doru
On 8 Aug 2011, at 22:35, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I just pushed a change removing the selfloop exclusion in scoping
methods.
Ignoring the 60+ tests that needed to be updated, most of the work
consisted in finding the right definition for
FamixMooseOutgoingCompositeQueryResult>>collectAtScope:
But this did not involve playing with the 'receiver' instance
variable as mentioned in the emails.
All (updated) tests are green
The initial behaviour should be available by calling explicitly
'withoutSelfLoops' on the result of a at___Scope (although I
realize
I did not test that explicitly).
nicolas
----- Mail original -----
> De: "Tudor Girba" <tudor(a)tudorgirba.com>
> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
> Envoyé: Vendredi 29 Juillet 2011 13:54:02
> Objet: [Moose-dev] Re: MooseChef scoping should not exclude self
> loops
> Hi,
>
> On 29 Jul 2011, at 13:48, Simon Denier wrote:
>
>>
>> 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
>
> Right, this is was my idea as well :).
>
> Cheers,
> Doru
>
>
>
>>
>>
>>>
>>> Any ideas?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On 29 Jul 2011, at 11:26, Simon Denier wrote:
>>>
>>>>
>>>> On 28 juil. 2011, at 23:10, Nicolas Anquetil wrote:
>>>>
>>>>> 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
>>>
>>> --
>>> 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
>>
>> --
>> Simon Denier
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Reasonable is what we are accustomed with."
>
>
> _______________________________________________
> 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
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11 Aug
11 Aug
1:37 p.m.
On 9 août 2011, at 12:27, Tudor Girba wrote:
Hi Nicolas,
Thanks for looking into this.
I would prefer to keep the previous separation. In fact, it seems to me that we can
obtain the same results as you have now by simply commenting the reject statement from:
MooseQueryResult>>collectAtScope: aScopeSymbol
| sourceScope |
sourceScope := receiver perform: aScopeSymbol.
^ self newObjectResultWith:
((self primCollectAtScope: aScopeSymbol)
"reject: [ :scope | sourceScope mooseIncludes: scope
]") "exclude self loops"
This is a tricky change and we should look into it closely. My solution would be to:
- remove the default reject (see above)
- add the receiver to MooseObjectQueryResult
- implement MooseObjectQueryResult>>withoutSelfLoops to use it
Totally agree with this.
Nicolas, if you need to temporarily hack MooseChef, you can just remove the reject:
statement above.
--
Simon Denier
5:56 p.m.
----- Mail original -----
De: "Simon Denier"
<simon.denier(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Jeudi 11 Août 2011 13:37:49
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self loops
On 9 août 2011, at 12:27, Tudor Girba wrote:
OK
"- remove the default reject (see above)"
This is what I did and so MooseQueryResult>>collectAtScope: basically calls
primCollectAtScope: and create a MooseObjectQueryResult with the result
This is why I removed primCollectAtScope:
So, the problem here seems more like a programming philosophy clash.
I must admit I am not too much found of creating tiny methods that call tiny methods that
call tiny methods.
Understanding this forces one to navigate a lot in the source code which is not fun.
In the present case I have a short collectAtScope: method that as the same length as the
current primCollectAtScope: but does not require the intermediary step.
"- add the receiver to MooseObjectQueryResult"
this one I don't get. AFAIK, receiver is already there and it just works
"- implement MooseObjectQueryResult>>withoutSelfLoops to use it"
OK I did it quickly, but I need to test
nicolas
Hi Nicolas,
Thanks for looking into this.
I would prefer to keep the previous separation. In fact, it seems to
me that we can obtain the same results as you have now by simply
commenting the reject statement from:
MooseQueryResult>>collectAtScope: aScopeSymbol
| sourceScope |
sourceScope := receiver perform: aScopeSymbol.
^ self newObjectResultWith:
((self primCollectAtScope: aScopeSymbol)
"reject: [ :scope | sourceScope mooseIncludes: scope
]")
"exclude self loops"
This is a tricky change and we should look into it closely. My
solution would be to:
- remove the default reject (see above)
- add the receiver to MooseObjectQueryResult
- implement MooseObjectQueryResult>>withoutSelfLoops to use it
Totally agree with this.
Nicolas, if you need to temporarily hack MooseChef, you can just
remove the reject: statement above.
12 Aug
12 Aug
10:15 a.m.
On 11 août 2011, at 17:56, Nicolas Anquetil wrote:
----- Mail original -----
By removing you mean renaming #primCollectAtScope: as #collectAtScope: in all subclasses?
De: "Simon Denier"
<simon.denier(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Jeudi 11 Août 2011 13:37:49
Objet: [Moose-dev] Re: MooseChef scoping should not exclude self loops
On 9 août 2011, at 12:27, Tudor Girba wrote:
OK
"- remove the default reject (see above)"
This is what I did and so MooseQueryResult>>collectAtScope: basically calls
primCollectAtScope: and create a MooseObjectQueryResult with the result
This is why I removed primCollectAtScope: Hi Nicolas,
Thanks for looking into this.
I would prefer to keep the previous separation. In fact, it seems to
me that we can obtain the same results as you have now by simply
commenting the reject statement from:
MooseQueryResult>>collectAtScope: aScopeSymbol
| sourceScope |
sourceScope := receiver perform: aScopeSymbol.
^ self newObjectResultWith:
((self primCollectAtScope: aScopeSymbol)
"reject: [ :scope | sourceScope mooseIncludes: scope
]")
"exclude self loops"
This is a tricky change and we should look into it closely. My
solution would be to:
- remove the default reject (see above)
- add the receiver to MooseObjectQueryResult
- implement MooseObjectQueryResult>>withoutSelfLoops to use it
Totally agree with this.
Nicolas, if you need to temporarily hack MooseChef, you can just
remove the reject: statement above.
So, the problem here seems more like a programming philosophy clash.
I must admit I am not too much found of creating tiny methods that call tiny methods that
call tiny methods.
Understanding this forces one to navigate a lot in the source code which is not fun.
mmm, in this case I don't see another clean way to do it. #collectAtScope: is (was) a
template method and #primCollectAtScope: a hook overridden in subclasses. (although I
don't like the name)
In the present case I have a short collectAtScope: method that as the same length as the
current primCollectAtScope: but does not require the intermediary step.
"- add the receiver to MooseObjectQueryResult"
I guess Doru meant to add the scope
this one I don't get. AFAIK, receiver is already there and it just works
"- implement MooseObjectQueryResult>>withoutSelfLoops to use it"
OK I did it quickly, but I need to test
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon Denier
5020
days inactive
5035
days old
13 comments
3 participants
participants (3)
-
Nicolas Anquetil -
Simon Denier -
Tudor Girba