reviewing moose chef
Locked
 
|
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. 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. 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. 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? Cheers, Doru -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
hu not much time these days, I almost missed that one. On 27 avr. 2011, at 23:34, Tudor Girba wrote: > 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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: > >> 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. Great. >> >> >> 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 I thought something was fishy :). I will fix that. Cheers, Doru > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 :) Cheers, Doru On 28 Apr 2011, at 08:36, Tudor Girba wrote: > 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: >> >>> 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. > > Great. >>> >>> >>> 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 > > I thought something was fishy :). I will fix that. > > Cheers, > Doru > > > >> >> -- >> Simon Denier >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > -- www.tudorgirba.com "Some battles are better lost than fought." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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: > >> 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: >>> >>>> 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. >> >> Great. > >>>> >>>> >>>> 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 >> >> I thought something was fishy :). I will fix that. >> >> Cheers, >> Doru >> >> >> >>> >>> -- >>> Simon Denier >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." >> >> >> > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |