29 Apr
2011
29 Apr
'11
12:20 a.m.
On 29 avr. 2011, at 00:07, Tudor Girba wrote:
Hi,
I am having second thoughts about making the QueryResult a group. It should be left as a
low level mechanism with the least possible overhead. We can always call asMooseGroup :)
That makes sense too :)
QueryResults are strange objects: basically they are just collections of data but also
embed metadata to enable filtering/scoping of their data based on the original query.
Cheers,
Doru
On 28 Apr 2011, at 08:36, Tudor Girba wrote:
I thought something was fishy :). I will fix that.
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon Denier
Hi Simon,
On 28 Apr 2011, at 01:13, Simon Denier wrote:
hu not much time these days, I almost missed that one.
Thanks for taking the time to look into this.
On 27 avr. 2011, at 23:34, Tudor Girba wrote:
Great. Hi,
I am going over Moose Chef. It's quite cool :).
Here are some issues I found:
1. MooseQueryResult currently inherits from Collection. It would be more useful if it
would be a MooseGroup because we could directly navigate it in the Moose Finder.
I already played with it and it looks like it is not too problematic to get this working.
I got 237 of 240 tests green. The 3 left are due to the Composite not working quite
properly due to a small mismatch between the semantics of Group and Collection.
Is there a reason for why we would want a Collection? If not, I will try to get it fully
working and then commit.
Not much except that when building MooseChef, it seemed more useful to inherit the full
power of Collection just in case. If we can make it work without inheritance, it's ok.
2. I like the filters, but they would need to be extended for handling groups of
entities. For example, now we can say outOfPackage:, but we should also be allowed to
specify outOfPackages:. This should not be hard.
indeed
3. Right now, we can work with one entity as a starting point (namespace, package, class
or method). We should also be able to have Groups as starting point. For this, I guess we
would need some other Traits.
I also think it should be part of the API. I settled down on entities because with
filters and scopes, it was already quite a lot of combinations to test and manage.
4. There are two references to MooseCompositeQueryResult in TScopingEntityQueries and in
TDependencyQueries. This class does not exist. First these methods seem to be overridden
in the classes. Second, I guess it should be MooseOutgoingCompositeQueryResult. Am I
correct?
mmm, actually it may be a bug with the 'Rename class' refactoring which does not
see traits. Instead of renaming the reference in the trait method, it did the renaming in
the methods as seen in the classes, which led to overriding the trait method in all
classes. Interesting.
So:
1) replace the missing reference by MooseOutgoingCompositeQueryResult in the trait
TDependencyQueries
2) remove all overriding methods in the using classes since they are redundant
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."