don't get me wrong, I am not asking for anything.
I don't know exactly what is your ultimate goal, so I am merely brainstorming.
Since I have no concrete application case (what is the concrete problem?) I am using
moose chef as inspiration.
nicolas
On 20/06/12 14:04, Andrea Caracciolo wrote:
Lift was initially born to materialize implicit
relationships derived from low level associations.
Moose chef is a query engine for famix models. This means that it analyses a given model
and returns only concrete associations.
What i understand from your comments is that you would like to port some of the querying
functionalities offered by chef to lift.
I tried to make up a list of possible requirements:
- query concrete associations by applying a selector on an entity/group
# in chef: aMethod queryAllIncomingInvocations
- query concrete associations by applying a selector on entities contained in the
receiver entity/group
# in chef: aNamespace queryAllIncomingInvocations
- query inferred associations by applying a selector on entities contained in the
receiver entity/group
# in chef: not supported
- filter returned associations by applying a custom select block
- filter returned associations by source/target class type
- filter returned associations by target scope (e.g: target entity must be within
anEntity/aGroup)
# in chef: aMethod queryOutgoingReferences opposites withinPackage: aPackage
- transform returned associations by applying a custom collect block
- transform each returned association to its source/target entity
# in chef: aMethod queryAllIncomingInvocations opposites
- return entities of a specified class type containing the "to" part of the
returned associations
# in chef: aMethod queryOutgoingReferences atPackageScope
Are they correct ? is the list complete ?
but may be you do not have to wrap all your
results in LifAssociations and can have mixed results with famix and lift associations
It's already like this. concrete low level associations are usually (when
possible) taken as is.
If you execute: (self lift: #incomingInvocations from:self mooseModel allMethods)
asMooseGroup.
You will see that the subassociations are of type FAMIXInvocation.
However take care that you are implicitly
restricting your relationships to be binary and directed (from/to)
What if I want a "sibling" relationship?
You are right. My supposition
is that all the associations are one-to-one. FAMIXAssociation has a "from" and a
"to" field.
How would you handle one-to-many associations ?
If you pass the selector to the specified receiver and you get multiple entities would
you treat it as a one-to-many association ?
"to" and "from", as fabrizio said, do not have any predefined
semantic. They just follow the direction of the selector (from is the message reciever and
to is the result).
Finally, you always give example of queries on
moosegroups, did you exclude queries on single MooseEntity?
I will soon add support
for mooseEntities too.
Cheers,
Andrea
On Jun 20, 2012, at 9:57 AM, Stéphane Ducasse wrote:
> On Jun 19, 2012, at 7:30 PM, Fabrizio Perin wrote:
>
>> Hi,
>>
>> 2012/6/19 Nicolas Anquetil<Nicolas.Anquetil(a)inria.fr>
>> On 19/06/12 17:10, Andrea Caracciolo wrote:
>> 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?
>>
>> Sorry Nicolas but I don't follow you. All the relations in Moose are binary:
any relation is just among two entities. If I have a one to many relation than I will have
multiple relation objects with the same sender and different receivers. Also the lift
relation it is not necessarily directed. It is the rationale that makes it directed or
not. From and to don't have to mean that the relation goes from the from part and goes
to the to part. An attribute that specify if the lift relation is directed or not could be
useful to distinguish the case.
> Hi fabrizio
> Multiple inheritance is managed as different relationships? I do not remember :)
>
>> 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).
>>
>> quite impossible to return normal relations since Lift infers and returns
relations that do not exist.
but may be you do not have to wrap all your
results in LifAssociations and can have mixed results with famix and lift associations
> ?
>
>
>> The rest of your email about helper methods to return directly the models could
make sense in some cases.
>>
>
Finally, you always give example of queries
on moosegroups, did you exclude queries on single MooseEntity?
>>
>> A query to a moosegroup of one entity is it not the same?
>>
>> Cheers,
>> Fabrizio
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch