On 5 déc. 2011, at 12:27, Nicolas Anquetil wrote:
Finally, I still have some questions (Simon?)
- the trait TScopingEntityQuery seems to exist only to be added to FamixScopingEntity. Is that so?
Why having a trait in this case? Consistency? If so, may be it should be documented (comment).
Yes. It seemed more appropriate to create a generic container specializing TDependencyQueries for "scopes". At least it keeps most generic things related to MooseChef close together (in dedicated classes/traits): only the most specific stuff goes into Famix classes.
Also, it's kind of a by-product of MooseChef evolution (at first I wasn't sure how much could be generalized from Package and Namespace - it just gradually evolved into this thing).
- MooseOutgoingCompositionQueryResult does not use TDependencyQueryResult whereas its sisters (MooseOutgoing/IncommingQueryResult) do. This means MooseOutgoingCompositionQueryResult is lacking many selectors that its sisters have (opposites, ...)
Error or feature?
Feature at the time, error if you want. It's just not always possible to tell what's the right semantics for every possible combination of queries + selectors.
In that case, since MooseOutgoingCompositionQueryResult groups different kinds of associations, I didn't have a use case where I would request 'opposites' of a composite result which includes invocations as well as references, etc : it would return a bunch of classes and methods. Now it could be useful for a consistent API, but I don't see a use case.