5 Dec
2011
5 Dec
'11
3:06 p.m.
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.
--
Simon Denier