On 19/06/12 17:10, Andrea Caracciolo wrote:
Hi Nicolas,
1) the asMooseGroup is just a standard moose method used to convert a
collection into a MooseGroup object.
I will probably move it in the lift:from: method.
No filtering option is currently supported.
What you get right now are objects of type FAMIXLiftedAssociation
representing inferred associations.
These objects have a reference to the source and target high level
entities they connect and to the low level concrete associations which
they abstract.
One possible extension (as you suggested) could be adding the
following method:
lift: aSelector from: aMooseGroup filter: aBlock
and some shortcuts like:
lift: aSelector from: aMooseGroup sourceEntities --> aBlock :=
[:each | each from]
lift: aSelector from: aMooseGroup targetEntities --> aBlock :=
[:each | each to]
2) is point one answering your question ?
Yes.
However take care that you are implicitly restricting your relationships
to be binary and directed (from/to)
What if I want a "sibling" relationship?
It might be implemented in a way that contradict your hypotheses.
The roles might have different names than to/from and it could be
interesting (or not) to take this into account just as you have "lift:
aSelector"
This could mean that instead of returning a collection of
FAMIXLiftedAssociation, you would return a LiftedResult that would
contain a collection of "normal relationships" (whatever they are).
The second way is how mooseChef treats the result of its queries.
3) I'm not sure i understand your question.
Scoping is implicitly defined by the entities contained in the
MooseGroup on which the query is executed and the MooseGroup specified
in the from parameter.
This means that if you execute:
highLevelGroup := MooseModel root first allNamespaces.
lowLevelGroup := MooseModel root first allMethods.
(highLevelGroup lift: #incomingInvocations from:lowLevelGroup)
asMooseGroup.
you will get a set of associations connecting namespaces (high level
scope) and these associations will abstract concrete association
existing between entities of type method (low level scope).
Currently you always return relationships, so scoping might be less
important (still ...)
But if we come back to my first point, then it changes a lot.
If MooseChef sensed the need to return either associations or entities,
it might be an indication that you could need it too (again reasoning
completely abstractly ids difficult, it would depend on the exact use
cases).
And if you allow returning entities, then scoping can become important:
when I want all incoming invocation to a package, I might want the
invocations themselves, or the packages they originate from, or the
classes, or the methods, ...
thus scoping.
It might also be that one relationship may have different to or from
entities.
Consider for example FamixReferences that might originate from a method
or from a class and target, variables, parameters, or attributes.
I might be interested only in the references to attributes and coming
from classes ...
I don't know how general you want to be so I am reasonning at the most
generic level I can manage.
Finally, you always give example of queries on moosegroups, did you
exclude queries on single MooseEntity?
(Not that it would change much to the discussion, only to the
implementation)
nicolas
I hope i answered your question.
Let me know what you think about.
cheers,
Andrea
On Jun 19, 2012, at 2:44 PM, Nicolas Anquetil wrote:
> Hi Andrea,
> (and doru incidently)
>
> The "more generic" part of your goal was not explicited in the
> previous email, so the mention of moosechef and the examples, led me
> on a wrong path.
>
> you can safely ignore my previous comment :-)
>
> Now, keeping an analogy with MooseChef, it implements thing that you
> might want to consider (at this level of abstraction it's a bit hard
> to tell):
>
> - relation vs. entities
> can you filter the results to return either the relationships or
> the entities they relate?
> Is that what 'asMooseGroup' is doing? If so you might want to
> consider some other name (eg 'asEntities')
>
> - relation roles
> MooseChef allows to request either the 'to' or 'from' end of an
> association, can you similarly specify the 'selector1' or 'selector2'
> (or 'selector3', ...) roles of your generic relationship?
>
> - scoping
> Can you restrict the resulting entities/relationship to be of a
> given type?
>
> as we are at a very abstract level, it might be better to offer a
> filterBlock and let the user define what kind of filter he whishes to
> apply?
>
> nicolas
>
> PS: I had a glance at your code. The mehtods look suspiciously long
> for a smalltalk implementation ...