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@inria.fr À: "Moose-related development" moose-dev@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@tudorgirba.com À: "Moose-related development" moose-dev@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.
you did not commit the tests :)
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?
- 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 -----
De: "Tudor Girba" tudor@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev