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 ...